bug: a fault between the loop claim and the run-row close leaves the loop "running" forever #3316

Summary

services/loop_service.py::advance_on_terminal makes two separate writes:

1. It records "run N done" on the loop row (the claim).
2. It closes run N's row (_close_run).

If a transient database error (for example database is locked) or a process kill lands between the two, the exception is swallowed and run N stays running. Neither recovery path can then fix it:

• A redelivered terminal is refused, because the loop already says "run N done".
• reconcile_after_restart refuses for the same reason.

The loop shows "running" permanently. That contradicts the module's stated guarantee that a restart loses nothing.

Repro: make finalize_loop_run raise once, start a 3-run loop, redeliver the terminal, then run reconcile. Run 1 is still running, and run 2 is never dispatched.

Context

Every execution terminal reaches this code through services/event_dispatch_service.py. Found by the 2026-10-06 /edge-cases sweep. A control test shows that the same fault one write later is recovered correctly.

Acceptance Criteria

• The claim and the run-row close are atomic, or reconcile and redelivery can detect and repair a claimed-but-unclosed run.
• tests/unit/test_ec_loop_service_edges.py::TestRestartMidAdvance::test_m56_fault_after_claim_is_recoverable_on_restart passes with its marker removed.