fix(gateway): offload SessionStore calls off the event loop via asyncio.to_thread

[kenyonxu]

Summary

PR #55159 added AsyncSessionDB to offload SessionDB calls from the gateway event loop, and even included an AST guard to prevent new raw on-loop calls. But SessionStore in gateway/session.py creates its own SessionDB() directly (line 949), bypassing the AsyncSessionDB facade entirely. So every get_or_create_session → _is_session_ended_in_db → db.get_session chain still runs synchronously on the event loop.

On a large state.db (~1.4 GB in production), this blocks the loop for seconds to minutes, starving Discord/Slack heartbeats and delaying session activation (#53297 — 15-30s delay for existing sessions).

This PR follows the exact same approach as #55159: SessionStore internals stay fully synchronous (zero changes), and all hot-path callers wrap calls with await asyncio.to_thread(self.session_store.method, ...).

Changes

Commit 1: Offload session store calls (gateway/run.py, gateway/slash_commands.py)

~24 call sites wrapped with asyncio.to_thread:

• get_or_create_session, switch_session, update_session
• load_transcript, rewrite_transcript, rewind_session
• reset_session, set_model_override, _save

Commit 2: Async-ify compression-in-flight check (gateway/run.py)

_session_has_compression_in_flight blocked the event loop twice on the message hot path:

1. Under session_store._lock during _ensure_loaded_locked (JSON read)
2. Via db.get_compression_lock_holder (SQLite SELECT)

Both sources are now offloaded via asyncio.to_thread. The method signature changed from def to async def; the call site at _handle_active_session_busy_message adds await.

Why not fix this inside SessionStore?

The Threading.Lock contract on SessionStore is preserved — all internals remain synchronous and thread-safe. The fix is purely at the call boundary, matching the pattern established by #55159 for _session_db.

Related

• Fills the gap left by fix(gateway): route SessionDB calls off the event loop via AsyncSessionDB #55159 (AsyncSessionDB)
• Most likely fixes [Bug]: Telegram existing sessions can take 15-30s to activate while new chats respond immediately #53297 (Telegram existing sessions take 15-30s to activate)
• Follows the same to_thread pattern as merged PR fix(gateway): offload channel directory session scans off the event loop #60984 (channel directory offload)
• The channel directory fix (fix(gateway): offload channel directory session scans off the event loop #60984) already landed upstream via a separate PR

Verification

• tests/gateway/test_compression_in_flight_check.py — 7 tests (includes thread-offload verification)
• tests/gateway/test_session.py — 100 tests
• tests/gateway/test_session_store_runtime_stale_guard.py — 11 tests
• tests/gateway/test_compression_interrupt_demotion_56391.py — existing tests adapted
• 119 passed across the affected test files

[alt-glitch]

This was generated by AI during triage.

Related: #60980 (api_server SessionDB offload) and the merged event-loop-starvation cluster #60984 / #53603 / #52090. This PR closes a distinct hole -- SessionStore in gateway/session.py instantiates its own SessionDB() directly, bypassing the AsyncSessionDB facade #55159 added, so the get_or_create_session hot path still ran sync SQLite on the loop. Same asyncio.to_thread approach, different call site; not a duplicate.

[kshitijk4poor]

Merged via #61905 with your commits and authorship preserved. The salvage also incorporated #61847, fixed the missing awaited compression check, and added a single async SessionStore boundary plus concurrency guards. Thank you!