fix(state): route session-resume reads through the WAL read-only connection

[pierrenode]

Summary

• get_messages_as_conversation, get_resume_conversations, and get_ancestor_display_prefix still acquired self._lock before reading, even though the recent WAL read-path split (per-thread read-only connections via _read_ctx()) was meant to remove exactly this choke point from every recall/browse read. These three are arguably the hottest reads in the file — every session resume across the gateway, CLI, and ACP adapter goes through one of them — so a resume racing a burst of concurrent-session writer flushes still convoys behind them the same way the already-fixed paths used to (measured convoy on the original fix: a 0.23s query stretching to 112s under 6-8 concurrent turns).
• _session_lineage_root_to_tip — the lineage-walk helper shared by all three functions above, plus get_conversation_root — had its own independent self._lock use. Converting only the three outer functions is not enough: they all call this helper as their first step, so it needed the same conversion or the block would just move one frame down.
• Both changes mirror the exact with self._lock: self._conn.execute(...) → with self._read_ctx() as conn: conn.execute(...) pattern already applied to get_session, get_messages, get_messages_around, get_anchored_view, and search_messages.

Test plan

• Added test_session_resume_reads_do_not_take_writer_lock to tests/test_session_db_read_path_split.py, mirroring the existing test_reads_do_not_take_writer_lock pattern (holds self._lock in the main thread, asserts the reader thread completes without blocking).
• This dev venv links SQLite 3.50.4, which is below Hermes's WAL-reset-bug threshold (3.51.3), so the runtime falls back to journal_mode=DELETE and every requires_wal-marked test — including the new one — skips here, same as its siblings. Verified the fix empirically instead: a standalone script that forces journal_mode=WAL + _wal_active=True on a temp SessionDB, holds self._lock in the main thread, and calls all three functions from a second thread.
  • Before the fix: the reader thread blocked for the writer's full lock-hold duration (first on get_messages_as_conversation, then again on get_resume_conversations via the un-converted _session_lineage_root_to_tip).
  • After the fix: all three complete in well under a millisecond while the lock is held.
• uv run --frozen --extra dev python -m pytest tests/test_hermes_state.py tests/test_session_db_read_path_split.py tests/cli/test_cli_resume_command.py tests/cli/test_resume_display.py tests/tui_gateway/test_protocol.py tests/test_tui_gateway_server.py tests/hermes_cli/test_context_switch_guard.py -q — 1119 passed, 7 skipped (WAL-gated), no regressions.
• ruff check hermes_state.py tests/test_session_db_read_path_split.py — clean.

[teknium1]

Thanks for finding the remaining transcript-read locks. The three converted methods still take self._lock on current main (hermes_state.py:6363, :6544, :6598), and _read_ctx() is the established WAL-safe mechanism (hermes_state.py:2061).

Problems

• Normal resume still blocks before these reads: resolve_resume_session_id() takes self._lock at hermes_state.py:6287 and calls get_compression_tip(), which locks at hermes_state.py:4950. Current TUI resume calls the resolver at tui_gateway/methods_session.py:364 before get_resume_conversations() at :496; CLI and gateway have the same resolver step.
• The added test covers the three converted reads but not that resolver/compression-tip preamble, so it cannot establish the stated no-convoy contract for a normal resume.

Suggested changes

• Convert the read-only queries in resolve_resume_session_id() and get_compression_tip() to _read_ctx() as well, retaining its DELETE-mode fallback.
• Add a WAL-gated writer-lock regression case for resolving a compression continuation, then cover the full resume sequence.

Automated hermes-sweeper review.

[teknium1]

This proves the three converted methods no longer take the writer lock, but normal CLI/gateway/TUI resume first calls resolve_resume_session_id(). That helper and its get_compression_tip() preamble still lock on current main, so please add a compression-continuation case that covers the full resume read sequence.

[kshitijk4poor]

Merged via #77803 — thank you @pierrenode. Your commit was cherry-picked, so you remain the author in git history.

Nicely scoped fix: main's _read_ctx() infrastructure existed but the resume paths were still convoying behind writer flushes, and your routing of exactly those four read sites (with the DELETE-journal fallback preserved) was the right-sized change. Your requires_wal skip guard on the new concurrency test was also correct engineering — it skipped cleanly on our SQLite-3.46.0 runner and exercises wherever WAL is active. The only salvage work was re-anchoring one hunk after main centralized the SELECT column list into _CONVERSATION_ROW_COLUMNS. 178 state tests green on the merged tree.