fix(session-db): advance flush cursor per committed message

[LeonSGP43]

Summary

Fixes the remaining duplicate-write failure mode from #12563: when _flush_messages_to_session_db() writes several messages and one append_message() fails mid-loop, any earlier rows that already committed must not be retried on the next flush.

The current full-success path already avoids duplicate writes, and merged lazy-session creation work covers the missing-row side of the issue. This PR keeps the change narrow to the partial-failure cursor gap: advance _last_flushed_db_idx immediately after each successful append, while preserving the final success-path cursor assignment.

Why now

Under SQLite lock contention, append_message() can fail after one or more earlier messages have already committed. Previously the cursor stayed at the old value until the whole loop completed, so the next persist path retried committed rows and inflated message_count / transcript rows.

Test coverage

• Added test_flush_advances_cursor_after_each_successful_message, which simulates database is locked on the third append and verifies the retry resumes at the third message without duplicating the first two.

Verification run locally:

scripts/run_tests.sh tests/run_agent/test_860_dedup.py
scripts/run_tests.sh tests/run_agent/test_860_dedup.py tests/run_agent/test_compression_persistence.py tests/run_agent/test_413_compression.py tests/run_agent/test_compress_focus_plugin_fallback.py
python -m py_compile run_agent.py
git diff --check

Results:

• 10 passed, 4 warnings
• 31 passed, 4 warnings
• py_compile passed
• git diff --check passed

Fixes #12563

[alt-glitch]

Related to closed PR #19407 (same fix — advance flush cursor per-message). That PR was closed because the author believed the change was already in main, but inspection shows main still only advances the cursor after the full loop completes. This PR is a valid re-implementation of the same fix.