fix: prevent _last_flushed_db_idx overshoot after scaffolding pop

[529349029]

Summary

Fix a bug where state.db loses assistant responses when _drop_trailing_empty_response_scaffolding pops trailing messages before _flush_messages_to_session_db runs, causing _last_flushed_db_idx to overshoot len(messages) and skip all writes.

Root Cause

In _flush_messages_to_session_db, flush_from = max(start_idx, self._last_flushed_db_idx). When _persist_session calls _drop_trailing_empty_response_scaffolding(messages) first, trailing messages can be popped, reducing len(messages). But _last_flushed_db_idx was already set to the old (higher) value by a previous intermediate persist call. Result: flush_from >= len(messages), messages[flush_from:] is empty, nothing written.

Fix

if flush_from >= len(messages):
    flush_from = start_idx

Evidence

Session mpjo2msf4kzhz9 in state.db: user=26, assistant=123, tool=114 (missing ~43 assistant responses). Same session in WebUI local DB: user=26, assistant=166, tool=122 (complete).

[alt-glitch]

Competing with #31517 — both fix #31507 (_last_flushed_db_idx overshoot after scaffolding drop). This PR resets flush_from inside _flush_messages_to_session_db; #31517 clamps _last_flushed_db_idx in _persist_session (earlier in call chain) and includes regression tests.