Extends merged #28439 (quarantine corrupt kanban DBs for #26479) to also cover disk I/O error exceptions, not just "file is not a database" / "database disk image is malformed". Related: #30908 (index corruption), #31158 (WAL/SHM cache poisoning).

@ddblue0's testing in #31736 characterized this as "works as a mitigation" rather than a root fix, that framing's accurate. The persistent-connection refactor in that thread is the real root direction; this is defensive depth for when I/O errors still slip through. I won't be driving review follow-up myself; deferring disposition to maintainers. Keep as mitigation, close in favor of the root fix, merge alongside it, all fine on my end.

Closing as superseded — different direction than the one that landed. This PR proposes latching the dispatcher when SQLite raises "disk i/o error", but #33482 commit 5c49cd0ed (fix(state): never silently downgrade WAL to DELETE on transient EIO) specifically removed EIO from the WAL-incompatibility marker list because it's transient (page-cache pressure, brief lock contention, recoverable storage hiccups) — not a permanent filesystem property. Latching the dispatcher on EIO would re-pause healthy boards after a one-tick I/O blip.

The corrupt-board latch already exists on main via c94ad8981 (5-minute retry quarantine with fingerprint-change retry). A follow-up issue (#33486) refines that with exponential backoff + PRAGMA quick_check confirmation to distinguish transient errors from real corruption before latching. Thanks for tackling the same problem space.