Summary

Closes #3210

Fixes Telegram (and all gateway platforms) losing conversation history after a session reset.

Root Cause

Gateway agents are cached by session_key to preserve the frozen system prompt and tool schemas across turns. When a session resets (idle expiry, daily reset, /new), a new session_id is assigned — but the cached AIAgent instance still holds its original session_id.

On the next message after a reset:

1. get_or_create_session() creates a new session → new session_id
2. _run_agent() hits the agent cache → reuses the old AIAgent (session_id = old)
3. agent.run_conversation() completes → _flush_messages_to_session_db() writes to agent.session_id (the old session)
4. On the following message: load_transcript(new_session_id) returns empty → the model sees only 1 message

This explains the reporter's exact symptom: "sometimes it knows about previous messages" (the first few turns after restart, before any reset) and "most of the time it just completely forgets" (every turn after the first reset).

Fix

One block added after the cache hit, inside _run_agent():

if agent.session_id != session_id:
    logger.debug(
        "Cached agent session_id mismatch (%s → %s), syncing",
        agent.session_id, session_id,
    )
    agent.session_id = session_id
    agent._last_flushed_db_idx = 0

_last_flushed_db_idx is reset to 0 so that _flush_messages_to_session_db() writes all messages from the start of the new session (no messages have been flushed to it yet).

Why _last_flushed_db_idx = 0 is safe

The flush cursor tracks how many messages have already been persisted for the current session. After a reset, the new session has zero messages in the DB — so starting the cursor at 0 is correct. Without this reset, flush_from = max(len(history), 0) would still be 0 for an empty history, so the reset is belt-and-suspenders but necessary for correctness when _last_flushed_db_idx accumulated from the previous session's run.

Scope

Single file, 14 lines added. All 1453 gateway tests pass.