fix(state): purge gateway_routing entries when prune_sessions hard-deletes

[pierrenode]

What does this PR do?

prune_sessions() (hermes sessions prune) deletes sessions/messages rows and on-disk transcript files directly in hermes_state.py, bypassing gateway/session.py's SessionStore entirely. It never touched the gateway_routing table (#59203), so a routing entry (session_key -> full serialized SessionEntry) written before the prune stayed dangling, pointing at a session_id whose row no longer existed.

gateway/session.py's own stale-entry self-heal (_is_session_ended_in_db) does not catch this: its own docstring says a missing row returns False ("keep") — that check exists for a different case (an entry not yet persisted), not "the row was deleted out from under it". The next message on that session_key would rehydrate the stale entry, load an empty transcript via load_transcript(), and ensure_session()'s INSERT OR IGNORE would silently recreate a blank sessions row — the user sees the conversation lose all memory instead of either continuing normally or starting cleanly fresh.

This is the same failure class the gateway/session.py self-heal was originally built for (#54878, #52804: "stale sessions.json entry silently drops messages until restart") — now reappearing against the new gateway_routing table, and made more realistic to hit by #59327's --newer-than filters, which let an operator prune sessions from just hours ago instead of only 90-day-old ones.

Related Issue

No filed issue — found via cross-PR review of #59203 (gateway_routing table) and #59327 (expanded prune filters), both merged in the same window, neither cross-referencing the other's effect on this table.

Type of Change

• 🐛 Bug fix (data consistency — stale routing entry causes silent conversation-history loss)

Changes Made

• hermes_state.py: prune_sessions() now calls a new _purge_gateway_routing_for_sessions() helper after deleting session rows, which scans gateway_routing (scoped to sessions_dir, mirroring SessionStore._routing_scope()) for entries whose embedded session_id was just deleted, and drops them via the existing (previously unused) delete_gateway_routing_entries(). No-op when sessions_dir is not passed (can't compute scope) or when nothing was pruned — same graceful-degradation convention _remove_session_files already uses.
• tests/test_hermes_state.py: two new regression tests — test_prune_sessions_drops_stale_gateway_routing_entries (verified: fails without the fix, passes with it) and test_prune_sessions_without_sessions_dir_skips_routing_cleanup (no-sessions_dir case doesn't crash or touch other scopes)

How to Test

python3.11 -m pytest tests/test_hermes_state.py -k "gateway_routing or prune_sessions" -v --override-ini="addopts="

Also re-ran the full file and the gateway session-routing suite to confirm no regressions: tests/test_hermes_state.py (324 passed), tests/gateway/test_session.py (100 passed).

Checklist

• Read the Contributing Guide | Conventional Commits | No duplicate PR
• Single logical fix | Tests added | Platform: macOS
• Docs — N/A | Cross-platform — N/A

[teknium1]

Thanks for tracing a real consistency gap: current prune_sessions() deletes the session rows without coordinating routing state (hermes_state.py:6392-6402).

Problems

• The proposed DB-only deletion does not invalidate an already-running SessionStore. Its runtime guard intentionally treats a missing DB row as keep (gateway/session.py:1637-1661), so get_or_create_session() will retain the in-memory entry and a later whole-index save can restore the DB row (gateway/session.py:1870, 1910-1920, 1239-1245).
• The default sessions.json mirror remains intact. It is enabled by default (gateway/config.py:678-683) and is imported for DB-missing keys at startup (gateway/session.py:1080-1111), so a restart can rehydrate the stale mapping the patch removed from gateway_routing.

Suggested changes

• Please rework this around an explicit prune invalidation path that coordinates the live store and both persisted routing representations, without repurposing the intentionally permissive generic missing-row check.
• Add an integration regression covering an existing store and a restarted default-config store after CLI-style pruning.

Automated hermes-sweeper review.

[pierrenode]

Rebased onto current `upstream/main`. `gateway/session.py`'s stale-entry check was restructured into an explicit lock-read/no-lock-I/O/lock-write phase split since this PR's branch point — merged this PR's `_purged_by_prune` check into that structure (computed in the no-lock I/O phase alongside `_is_stale`, consistent with the refactor's own stated goal of keeping I/O out of the lock). `hermes_state.py`'s conflict was two independent, non-overlapping additions at the same insertion point — kept both.

The test-file conflict included a fragment of a pre-existing test (`test_force_new_skips_stale_check`) that turned out to belong to a class upstream has since restructured/renamed elsewhere in the same file — verified upstream's current `TestRuntimeStaleGuard` no longer ends with that test, so it wasn't something this PR removed; kept only this PR's own new test classes.

Mutation-verified: removing `_purged_by_prune` from the stale-entry condition breaks `test_purged_entry_creates_fresh_session`. Full `test_session_store_runtime_stale_guard.py` + `test_hermes_state.py` (245 tests) passes. Ruff clean.

(A broader `tests/gateway/test_session*.py tests/state/` sweep showed one unrelated failure — confirmed pre-existing test-order pollution by reproducing the identical failure against clean pre-fix `upstream/main` code with the same broad file selection.)

Squashed to a single commit on top of current `upstream/main`.