fix(db): retry transient SQLITE_IOERR instead of failing the caller

[halindrome]

Problem

withRetry in src/db-base.ts only treats SQLITE_BUSY / database is locked as retryable and rethrows everything else on the first attempt. SQLITE_IOERR falls into a gap:

• no retries — it fails the caller immediately, and
• isSQLiteCorruptionError() does not match it either, so no recovery path runs.

A single transient I/O blip — fs pressure, Spotlight/iCloud touching the DB mid-write, a WAL hiccup — therefore hard-fails the write. Observed in the field as ctx_fetch_and_index aborting a page index with disk I/O error, after which the session stops using context-mode tools entirely. The DB itself is healthy (PRAGMA integrity_check returns ok); only the one write failed.

Change

• Add SQLITE_IOERR / disk I/O error to a named TRANSIENT_ERROR_PATTERNS list so they get the same 3-attempt exponential backoff as SQLITE_BUSY.
• Derive the retry-exhaustion message's error class from the actual failure instead of hardcoding SQLITE_BUSY — reporting "database is locked" for an I/O failure sends the caller after the wrong root cause.

Deliberately NOT added to isSQLiteCorruptionError(): that path renames or deletes the DB file, which would destroy a healthy knowledge base over a momentary stall. Retry here; recover there.

Tests

tests/store.test.ts gains 50 lines covering: SQLITE_IOERR retried and succeeding on a later attempt, retry exhaustion reporting the I/O error class rather than SQLITE_BUSY, and non-transient errors still rethrowing on the first attempt.

Verification

• npm run typecheck — clean
• npm test — 4715 passed, 28 skipped, 3 failed
• tests/store.test.ts — 127/127 pass

The 3 failures (tests/session-hooks-smoke.test.ts ×2, tests/hooks/claude-stop.test.ts ×1) reproduce identically on unmodified next on this machine, so they are pre-existing and environmental, not introduced here.

Bundles are left untouched — .github/workflows/bundle.yml regenerates and commits them.