fix: SQLite WAL write-lock contention causing 15-20s TUI freeze

[teknium1]

Problem

Multiple hermes processes (gateway + CLI sessions + worktree agents) sharing one state.db caused WAL write-lock convoy effects. SQLite's built-in busy handler uses deterministic sleep intervals (up to 100ms between retries) that synchronize competing writers, creating 15-20 second freezes during agent init.

Root cause chain:

1. timeout=30.0 — SQLite retries the write lock for up to 30 seconds with deterministic backoff
2. 7+ concurrent connections prevent WAL checkpointing → WAL grew to 294MB
3. Bloated WAL slows all reads/writes (hash index traversal on every operation)
4. Deterministic backoff causes convoy effects — all processes wake and collide at the same time

Fix

• Replace 30s SQLite timeout with 1s + application-level retry (15 attempts, random 20-150ms jitter between retries to break convoys)
• Use BEGIN IMMEDIATE for explicit write-lock acquisition (fail-fast on contention)
• Set isolation_level=None for manual transaction control (prevents Python's implicit transaction management from conflicting with BEGIN IMMEDIATE)
• PASSIVE WAL checkpoint on close() and every 50 writes — keeps the WAL from growing unbounded
• All 12 write methods converted to _execute_write() helper

Results

Metric	Before	After
Init freeze	15-20s	<1s
WAL size	294MB (growing)	~4MB (stable)
Write contention	Visible on every py-spy dump	Zero across 3 concurrent sessions

Testing

• 4,355 unit tests pass (hermes_state, gateway, tools, CLI)
• Live tested: 3 concurrent CLI sessions with simultaneous messages — zero _execute_write contention on every py-spy sample
• Gateway restarted with new code, verified clean operation (zero SQLite errors)
• Sessions properly persisted: message counts, token tracking, clean exit with ended_at + end_reason
• WAL truncated from 294MB → 0, stayed at 4MB through all concurrent testing