Problem

Every kanban tool call opens two SQLite connections: a probe connection for PRAGMA integrity_check (timeout=5) and the main connection for actual work (timeout=30). The probe connection sees transient WAL states from other gateway processes during their checkpoint operations. It then incorrectly declares the database corrupt.

Evidence

73 .corrupt.*.bak files were created across 4 bursts since May 25. Backup sizes within a single burst are identical — same database, copied multiple times. All errors originate in _guard_existing_db_is_healthy() during connection open, never during writes. Four GitHub issues confirm the same pattern: #30445, #31618, #31502, and #31891. During live testing, the database was flagged corrupt 4 times by our own polling queries within minutes.

Root Cause

_guard_existing_db_is_healthy() in kanban_db.py opens sqlite3.connect(path, timeout=5) as an independent probe path. This connection has no relationship to the main connection and observes WAL checkpoint transients from concurrent gateway processes. The chain reaction is: integrity_check reports "malformed" → _backup_corrupt_db() creates a timestamped backup → KanbanDbCorruptError propagates → the worker retries and hits the same transient again. The retry loop produces ~70 backups in 5 minutes on a database that was never actually corrupt.

Before / After

BEFORE (two separate connection paths per call):
─────────────────────────────────────────────────
  kanban_tool_call()
    ├── sqlite3.connect(db, timeout=5)  ← PROBE (independent path)
    │     └── PRAGMA integrity_check
    │           ⚠ sees WAL transient from another gateway process
    │           → "malformed" → backup → KanbanDbCorruptError
    │
    └── sqlite3.connect(db, timeout=30) ← MAIN (never reached if probe fails)

AFTER (single pooled connection per process):
─────────────────────────────────────────────
  kanban_tool_call()
    └── get_connection() → POOLED connection (one per process+board)
          └── _check_db_health(conn, path)
                ✓ same connection, consistent state
                ✓ no separate path, no transient visibility

Fix

Two changes, no pragma tuning. First: _guard_existing_db_is_healthy() becomes _check_db_health(conn, path) — integrity check runs on the main connection, not a separate probe. Second: get_connection() implements a singleton pool (pattern from hermes_state.py SessionDB), reusing one connection per gateway process and board. connect() remains as a legacy wrapper for tests that need fresh non-pooled connections. No synchronous=FULL, no busy_timeout tuning, no checkpoint management — the elegance is simply: wrong connection architecture → correct connection architecture.

Why This PR Over Others

28 open PRs address kanban corruption, none merged. Most set pragma flags — synchronous=FULL (3+ PRs), wal_autocheckpoint (2 PRs), secure_delete, cell_size_check. Those treat symptoms. This PR addresses the architecture: two connection paths where one suffices, per-call connections where a singleton pool suffices. It complements #31891 (transaction merging) and #31795 (probe retry) without conflict. It works alongside #32322 (connection caching in GatewayRunner).

Tests

test_kanban_singleton_pool.py (new, 196 lines): 1000 rapid create+complete operations without corruption, concurrent connection integrity verification, singleton identity assertion, thread safety coverage. Existing suite: 172 passed, 7 skipped.

Related

Closes: None (addresses the corruption cluster). Related: #30445, #31618, #31502, #31891, #31795, #32322.