fix(runtime): mitigate SQLite contention with bounded recovery

[kingsword09]

Concurrent CLI processes can still fail with SQLITE_BUSY after the existing 10-second wait, while every usage fact starts another cleanup transaction. Add bounded recovery around audited native storage operations and reduce maintenance writes.

Related to #162. This is a contention mitigation; the production outcome is still unconfirmed. #162 remains open pending validation on the reporter's original Linux workload.

• Scope native busy waits to 25 ms per SQLite call, then retry eligible storage operations with asynchronous jittered backoff within a 30-second budget. Preserve the original connection timeout outside those calls.
• Serialize writes by database path within the process, preserve ordering within each priority class, and let pending conversation writes proceed between usage retries. Closing a store cancels its own queued writes and backoff.
• Preserve native transaction ownership and rollback. Retry only audited rollback-safe or ID-idempotent operations; keep model requests and completed tools outside the retry boundary.
• Check automatic usage cleanup at most once per connection every five minutes and skip its transaction when no rows are expired. Defer busy cleanup without failing a committed usage fact; retain explicit cleanup requests and the 30-day retention policy.
• Install the bridge after both migration paths through a required, idempotent runtime patch. Reject changed or partial patch boundaries and document the recovery scope.

Validation completed locally on macOS:

• Type checking; 673 unit tests, 33 runtime integration tests, and 51 TUI tests passed, along with terminal smoke checks.
• Final Node 26.4.0 SQLite suite: 20 tests passed. Suite and follow-up regression checks also passed on Node 22.19.0 and 24.21.0.
• Twelve processes persisted 300 input promotions with matching messages, parts and usage records; integrity and foreign-key checks passed.
• Verified recovery after a 10.5-second lock, partial-write rollback, ordered updates, externally owned transactions, cancellation, and preservation of non-BUSY failures and non-idempotent counters.
• With expired usage present, 100 usage writes required one cleanup transaction instead of 100.
• Locked Desktop 3.14.3/runtime 0.16.9 synchronization, runtime/package validation, and npm tarball installation smoke passed.

Synchronous workflow-journal and permission-mode APIs retain their native behavior. Non-idempotent counter operations are ordered but are not replayed. There is no database schema change or sharding; sustained contention can still exceed the budget. Hosted Linux CI and reporter validation are still required before judging the production outcome.

[pkg-pr-new]

npx https://pkg.pr.new/zcode-app-cli@29b543f

commit: 29b543f