[tom-sapletta-com]

A ticket update can commit to authoritative YAML/evidence and then return HTTP500 when its disposable SQLite projection is locked. Defer only post-commit SQLITE_BUSY/SQLITE_LOCKED, persist an atomic invalidation token in freshness checks across processes, and let the normal index rebuild recover. Other index errors and all pre-write failures still propagate.

Regression coverage uses real SQLite writer contention for flat and sharded create/update/delete/move/evidence operations, HTTP acknowledgements, a separate reader process with a warm signature cache, evidence replay/conflict, stale CAS, actual SQLITE_LOCKED and extended error codes. It also checks that an invalidation-filesystem failure stays visible.

Ticket: ticket-258
Refs #316 (PLF-20365), parent PLF-20347. Native runtime rollout remains separately owned by #317/#313; this source PR does not modify a live package, data or lock.

Validation: 142 affected tests passed through Testless with outcome accounting and coverage; 28 new regression cases. Ruff and managed governance passed.

[tom-sapletta-com]

The failure is interpreter-specific, which should narrow this quickly.

From the executor job log:

Using CPython 3.10.20 interpreter at: /opt/planfile-procache94cb311-3.10.20/bin/python
FAILED tests/test_ticket_radar.py::test_creation_persists_advisory_before_journal[planfile-True-sharded-yaml]
FAILED tests/test_ticket_radar.py::test_creation_persists_advisory_before_journal[store-False-single-yaml]
AssertionError: assert 'Zażółć gęślą...arkdown**\n  ' == 'Zażółć gęślą...ge authority.'
====== 2 failed, 1937 passed, 12 skipped in 343.11s (0:05:43) ======

Key detail: this is the 3.10.20 leg. On the current interpreter the same suite is green here (1937+ passed, GOV-PASS), so whatever differs is version-sensitive in the rendered advisory text — the actual value ends with **markdown** and two trailing spaces where the expected value ends with ge authority.. That smells like line wrapping or trailing-whitespace handling in the advisory body, not the index-contention logic this PR is about.

Two things worth checking in that order:

1. Reproduce with 3.10 explicitly: /opt/planfile-procache94cb311-3.10.20/bin/python -m pytest -q tests/test_ticket_radar.py::test_creation_persists_advisory_before_journal. If the advisory is built with textwrap or an f-string spanning lines, 3.10 and 3.13 can differ.
2. Print the two values side by side in the test failure rather than relying on the truncated diff — the assertion is currently cutting both strings at the same prefix, so the first differing character is invisible in the log.

I did not touch the branch or the tests. Nothing was merged.

[tom-sapletta-com]

For comparison, semcod/planfile#318 passed the same gate yesterday (6 local test gates against main ff2193f), so the gate itself works for this repository — worth re-running once before assuming the branch is at fault.