PR Gates / CI image pin matches docker/ci (pull_request) Successful in 11s
PR Gates / Docs update reminder (pull_request) Successful in 12s
PR Gates / decisions lifecycle (pull_request) Successful in 18s
review-verdict/h10 Awaiting review verdict for 5077408
Review verdict / Set review-verdict status (pull_request_target) Successful in 10s
PR Gates / Script tests (pytest) (pull_request) Successful in 1m46s
Build ErsatzTV Image / Functional E2E (curl + UI contracts) (pull_request) Successful in 6m5s
Build ErsatzTV Image / API docs in sync (OpenAPI + endpoint index) (pull_request) Successful in 10s
Build ErsatzTV Image / Formatting (changed .cs conform to .editorconfig) (pull_request) Successful in 16s
Build ErsatzTV Image / EF migration integrity (SQLite + MySql) (pull_request) Successful in 20m47s
Build ErsatzTV Image / Build & test (.NET) (pull_request) Successful in 23m42s
Build ErsatzTV Image / Build & push image (amd64) (pull_request) Has been skipped
Round-3 cold review: `ex_repair` was recomputed by the last-moment re-read but never consulted after it, so the POST wrote the `$state` frozen at classification time. A stale overlapping run therefore posted its `success` straight over a sentinel another run had just written — burying a human rejection with no repair (the human row sits below the stale run's own high-water mark) and no log entry. This is the one path in the design that failed toward SUCCESS rather than `pending`, so it was not covered by the recorded residual, and it is reachable through exactly the run overlap this branch measured live (probe PR #722: the older run finished 20s after the newer one started). The guard is exact rather than conservative: a sentinel present at the FIRST read forces `state=pending`, so `success` together with `ex_repair=yes` at re-read time can only mean the sentinel arrived mid-run. Abstaining is then strictly correct and, unlike the retarget fence, needs no successor run — the sentinel row is already `pending` and already carries the re-post instruction. Mutation-verified three ways: removing the guard reddens the new mid-run test while its positive control stays green; making it unconditional on `ex_repair` reddens the fixed-point test and the positive control, proving the condition is precisely scoped and not merely present. Also strengthens the mark-ordering test to pin the status-history FETCH as well as its initialisation, closing the refactor evasion review flagged; sliding the fetch past the re-read now reddens it. Refs #706