fix: recover SessionDB flush cursor from persisted prefix

[hanzckernel]

SessionDB flushing now recovers from the persisted message prefix instead of relying only on the runtime conversation_history cursor. This prevents sessions whose raw JSON contains the full conversation, but whose SQLite messages table is empty or only partially written, from appearing as empty threads in the dashboard or hermes sessions export.

Changes

• Added SessionDB.count_messages(session_id) so the current number of persisted messages can be read with a lightweight query.
• Updated _flush_messages_to_session_db() to keep the existing in-memory cursor for duplicate prevention, while falling back to the persisted DB prefix when the runtime cursor has advanced past what was actually written.
• Added regression tests covering:
  • an empty DB while conversation_history already points at the end of the message list;
  • a partially persisted DB prefix while the runtime cursor has advanced past the remaining messages;
  • repeated flushes do not create duplicate message rows.

Verification

Passed:

python -m pytest tests/test_session_db_flush_cursor.py tests/hermes_state/test_resolve_resume_session_id.py -q -o 'addopts='
python -m py_compile run_agent.py hermes_state.py tests/test_session_db_flush_cursor.py
git diff --check

Result:

11 passed in 1.27s
py_compile passed
git diff --check passed

Notes

• This PR only fixes the new persistence write path; it does not backfill historical data.
• Sessions that were already affected still need a separate backfill from ~/.hermes/sessions/session_<id>.json into state.db before they will immediately appear in the dashboard/API.