Fix kanban dispatcher SQLite connection churn

[sntrblck-sudo]

Reuses the board connection for the readiness probe so the embedded gateway dispatcher does not open a second SQLite handle per board tick.

[teknium1]

Thanks for isolating the duplicate readiness-probe connection. The performance premise still holds on current main: gateway/kanban_watchers.py:1009 opens the dispatch connection, while gateway/kanban_watchers.py:1100 opens a separate connection for health telemetry after each tick.

Problems

• The submitted hunk targets the pre-extraction implementation in gateway/run.py. GatewayRunner now inherits GatewayKanbanWatchersMixin at gateway/run.py:2775, and the active watcher is in gateway/kanban_watchers.py; applying this diff would not update the live path without a focused port.
• gh pr diff 31768 shows substantial unrelated gateway reversions outside the dispatcher hunk, so the current diff is not safely scoped to the claimed fix.

Suggested changes

• Port only the tuple/readiness flow into gateway/kanban_watchers.py:975-1254, reusing the conn opened at line 1009 for has_spawnable_ready and has_spawnable_review.
• Move the regression coverage to that active path and assert one connection per board tick.

Automated hermes-sweeper review.

[teknium1]

This is the right narrow behavior, but current main no longer executes this watcher from gateway/run.py: GatewayRunner inherits GatewayKanbanWatchersMixin (gateway/run.py:2775), whose live connection/probe paths are gateway/kanban_watchers.py:1009 and :1100. Port this hunk to that mixin rather than applying it at the removed location.

[kshitijk4poor]

Thanks @sntrblck-sudo — the kanban dispatcher connection-reuse idea is sound (one connection per tick instead of open/close churn, correctly scoped inside the to_thread try/finally). Unfortunately this branch was cut from a stale checkout: alongside the ~40-line kanban fix, the commit reverts several unrelated features that landed on main earlier (gateway transient-network crash handling from #31066/#31110, media delivery-path filtering at 3 send sites, status-bubble editing from #30045, env-var config expansion, fallback-chain key resolution, and more), so it can't merge as-is. There's also one behavioral note on the fix itself: folding the readiness probe into the same tick/connection after dispatch_once masks the 'queue non-empty but dispatch broken' condition the stuck-tick watchdog exists to catch — the old independent probe still fired in that state. Closing this one; the connection-reuse approach is worth re-extracting onto current main with the watchdog probe kept independent, and we'd be glad to review that.