Problem

Gateway delivers assistant responses to the platform (confirmed in gateway.log), but the session DB ends up with no assistant rows between the user messages. When the next message arrives, the model loads a transcript full of "unanswered" user messages and re-answers all of them in one turn.

Root cause

Two pieces interact:

1. Agent — partial-stream recovery drops the assistant turn. In agent/conversation_loop.py, when the final assembled assistant message has no visible content but text was already streamed to the user, the recovery path sets final_response from the streamed text and breaks without appending an assistant message to messages. The turn-end _persist_session() then flushes a transcript whose tail is the user message — the user row survives (written by the turn-start crash-resilience flush), the assistant row never exists. This matches the issue's evidence exactly: response ready (…, 48 chars) logs a non-empty final_response while the DB has zero assistant rows.

2. Gateway — every fallback write is a silent no-op. Since state.db became the canonical transcript store (spec 002), append_to_transcript(..., skip_db=True) does nothing at all. The gateway skips all post-turn DB writes via skip_db=agent_persisted to avoid the bug: SQLite session transcript accumulates duplicate messages (3-4x token inflation) #860/Bug: User messages stored twice in state.db when agent and gateway both write to SQLite #42039 duplicate-write bug — correct for messages the agent flushed, but it means the gateway cannot backfill anything the agent's flush missed. The delivered response is silently dropped with no error anywhere.

Fix

One invariant, enforced at both layers: a delivered final_response must end up in the session transcript.

• agent/conversation_loop.py: the partial-stream recovery path appends the recovered text as a real assistant turn before breaking, so _persist_session() writes it and role alternation is preserved.
• gateway/run.py: when the turn's new messages contain no assistant text but a response was delivered, the gateway backfills the assistant row with skip_db=False. A response generated this turn cannot already be in the loaded history, so this cannot double-write; the bug: SQLite session transcript accumulates duplicate messages (3-4x token inflation) #860/Bug: User messages stored twice in state.db when agent and gateway both write to SQLite #42039 protections for user entries and agent-flushed messages are untouched (pinned by regression tests). Same reasoning for the existing not new_messages fallback branch, whose assistant write was also a no-op.

The gateway backfill also covers the fallback_prior_turn_content recovery (response sourced from an earlier tool-call turn's content, transcript tail ends at a tool message) and any future agent path that returns a response without representing it in messages — with an INFO log so occurrences are visible instead of silent.

Tests

• tests/run_agent/test_44100_partial_recovery_persistence.py — partial-stream recovery appends the recovered assistant turn; normal turns unchanged (exactly one assistant message).
• tests/gateway/test_44100_assistant_backfill.py — backfill fires when the turn has no assistant text (plain and tool-call turns), does NOT fire when the agent persisted the message itself (bug: SQLite session transcript accumulates duplicate messages (3-4x token inflation) #860/Bug: User messages stored twice in state.db when agent and gateway both write to SQLite #42039 protection intact), and the not new_messages fallback writes with skip_db=False.

tests/gateway/ + the neighboring run_agent persistence/streaming suites pass; the handful of failures present are identical with and without this diff (pre-existing, environment-dependent: shutdown forensics/systemd, Telegram MarkdownV2 escaping).

Fixes #44100