Avoid ambiguous HTTP 500 after durable ticket write when SQLite index is locked #316

Problem

PLF-20365: a ticket mutation can be durably saved and then return HTTP 500 when updating the disposable SQLite index fails with sqlite3.OperationalError: database is locked in _finish_index_mutation. The client cannot safely infer whether the write happened and retries risk duplicating side effects. This is distinct from #297 (contention before evidence append) and #313 (full-index repair liveness).

A local isolated diagnostic reproduced HTTP 500 with successful authoritative readback and exercised a candidate, but that candidate is not an approved change. Evidence on this host: semcod/planfile/.subactor/receipts/plf20365-diagnostic/result.json and paxlet-com/heyasa/.subactor/receipts/autonomy-focus-20261028/continuation/planfile-index-lock.log. Qualify against the current base and current deployed runtime rather than assuming the diagnostic copy is a release.

Acceptance

• Investigate all call sites and handle real SQLite BUSY/LOCKED contention after a completed durable mutation without falsely reporting failure or replaying the write. Preserve authoritative mutation serialization, CAS and idempotent evidence semantics. Do not hide unrelated errors or failures before the durable commit.
• Prove a stale projection cannot appear current to other workers; preserve correctness under concurrent writes, source changes and rebuilding, with eventual repair or a bounded typed recovery state. Do not delete or steal a lock, disable checks, or treat the cache as authoritative.
• Add meaningful store/API regressions covering post-write contention and authoritative readback, non-contention errors, duplicate/retry behavior, and separate-worker behavior as applicable. Run scoped checks and qualify two-worker runtime behavior.
• Use the declared controller, exact fenced lease and canonical v5 worktree. Work only in this issue's scope, preserve other agents' worktrees, and use current-base OneDev and independent Validator for publication. Runtime deployment requires its own admitted path and readback.

Session authorization: user asked to continue autonomous implementation, testing and protected publication through Heyasa; use one worker and one ticket. This is task consent, not a writer lease or independent approval.