Summary

Fix Kanban WAL-mode false corruption errors without serializing normal worker writes.

The previous bounded write-lock approach in #37350 proved that global serialization avoids the symptom, but it also defeats Kanban's parallel-worker design. This PR targets the lower-level false positive instead:

• skip the post-commit main-file length invariant while the connection is in WAL mode, because committed frames may still live in kanban.db-wal while the main DB file legitimately lags;
• keep the torn-extend invariant active for rollback-journal modes where the main DB file is authoritative;
• restore SQLite's default wal_autocheckpoint=1000 to reduce checkpoint churn under worker bursts while keeping synchronous=FULL for committed WAL frames;
• add a real multiprocess WAL smoke test that verifies concurrent writers complete without a global kanban.db.lock sidecar and leave quick_check / integrity_check clean.

Why not global write locking

A full cross-process sidecar write lock is safe but too expensive for the default path. Local stress showed the lock-based approach turned the same worker burst from seconds into roughly two minutes. Kanban is meant to get useful parallelism from worker subprocesses, so normal task/event writes should remain SQLite/WAL-concurrent.

This keeps the lock scope unchanged: first-connect/schema/WAL setup remains protected by kanban.db.init.lock; ordinary writes still use SQLite's BEGIN IMMEDIATE, busy timeout, WAL, and the existing corruption guards.

Supersedes #37350.

Verification

• python -m pytest tests/hermes_cli/test_kanban_db.py -q -o 'addopts='
  • 217 passed in 6.12s
• Local stress: 20 processes × 220 task creates against one WAL kanban.db
  • 4400/4400 writes completed
  • worker_error_count=0
  • quick_check=ok
  • integrity_check=ok
  • no kanban.db.lock sidecar created
  • elapsed about 3.1s on local macOS

Independent review completed before submission; duplicate test feedback was addressed.