fix(runtime): mitigate shared SQLite write contention

[mwotton]

Related to #162. This is a bounded contention mitigation, not a claim that sustained concurrent-write failures are fully resolved. Keep #162 open for reporter validation and upstream follow-up.

Why the original patch needed adjustment

The reporting host runs multiple headless agents and interactive sessions against one shared SQLite session database. Lock errors can escape as fatal Turn execution failed errors.

The currently pinned 3.12.3 runtime already opens SQLite with a 5-second timeout. Its asynchronous startup migration temporarily uses a shorter busy timeout and restores 5000 ms in finally. Setting 10000 ms immediately after new DatabaseSync(...) is therefore overwritten on the normal openStartup() path. Merely finding a pragma string in the bundle is not evidence that the active connection uses it.

Changes

• Apply the 10000 ms ordinary-write timeout after successful migrations on both synchronous construction and asynchronous startup. Preserve startup migration budgets, backoff, rollback, and failure cleanup.
• Keep the patch required and idempotent; verify both lifecycle insertion points rather than accepting an unrelated pragma string.
• Pin Bun and bun-types to 1.4.1 in development and release workflows.
• Replace the Bun-executed SQLite driver check with five real Node tests using the native vendored SqliteSessionStore, temporary databases, and independent Node processes.
• Build and pack once in CI, then test the exact validated artifact with Node 22.19.0, 24, and 26 on Linux and Node 24 on macOS.
• Document the reproduction and remaining limits in docs/SQLITE_CONCURRENCY.md.

Local validation

• TypeScript checking, locked runtime synchronization, runtime/package checks, terminal smoke tests, and tarball installation smoke passed.
• Bun 1.4.1: 629 unit tests, 43 TUI tests, and 21 runtime integration tests passed.
• All five Node SQLite tests passed against the packed artifact on Node 22.19.0, 24.21.0, and 26.4.0:
  1. effective timeout after synchronous open, asynchronous startup, and reopen;
  2. a native session write succeeds exactly once after an independent writer holds its lock for 6.5 seconds;
  3. a deliberately short timeout reports SQLITE_BUSY without writing a session, and the connection works after release;
  4. four independent processes migrate one fresh database and preserve all session writes;
  5. a killed writer's uncommitted changes do not survive reopen, and later writes succeed.

These are deterministic storage-level regressions, not a reproduction of every detail of the reporter's production fleet. Hosted CI must pass before merge.

Scope and follow-up

No schema changes, historical-data rewrite, automatic whole-turn retry, database sharding, or Desktop 3.14.0 runtime upgrade are included. A lock held beyond the timeout can still fail, and synchronous SQLite waiting can block the calling runtime's event loop.

After release, ask the reporter to test the same concurrent workload and share sanitized lock/turn-failure evidence. Upstream ZCode should investigate long transactions, contention diagnostics, and safe persistence-boundary recovery; blindly replaying an entire agent turn can duplicate external side effects.