[automation] Dispatch records 2 failed runs (09-17, 09-18) while the 09-17 receipt claims success — verify which is true

[JavaGT]

Found during the 2026-09-18 cross-fleet automation review (scheduler DB, read-only).

Evidence:

• automation_runs: scheduled 2026-09-17 03:30 → outcome failed, session ended ~4.7 min later, no error text recorded.
• Same again 2026-09-18 03:30 → outcome failed, ~4.5 min, no error text. No 09-18 receipt exists in artifacts/automation-receipts/2026-09-18/.
• Yet the 09-17 receipt (artifacts/automation-receipts/2026-09-17/missing-runid-attempt-1-libby-archiver-0330.md) reports status: success, started 03:31, finished 04:08 (~37 min), with tickets perf: bench gate anchors on the pre-campaign snapshot — add a run-over-run (last-accepted) or absolute-ms anchor so within-campaign regressions trip it #29–perf (evaluate): freeze/gate the deflate level choice — deflate_levels is informational, a level drift lands silently #31 and review briefs as evidence.

The dispatch layer says two consecutive failures; the receipt narrates a successful 37-minute wave that outlives the recorded session end by ~34 minutes. Both cannot be right.

Ask: investigate the 09-17/09-18 sessions (e.g. sess_d7d8a11b-c2ee-47ed-…) — did the receipted work actually happen? If dispatch is killing sessions early, receipts must not narrate post-death work (same class as Scope's #3372 future-dated receipts). This is evaluate/investigate, not implementation.

[JavaGT]

Verified from ground truth (git + artifacts), by run manual-catchup-20260919:

09-17: the work IS on the ground — the dispatch record is wrong. Commits b505f37 (#19 bench gate), e87cf8b + 3d26cf9 (#20 retry + review fixes) landed 2026-09-17 03:38–09:08, and the receipt itself was committed as 246b710 (09-17 09:14) with its check artifacts (artifacts/automation-receipts/2026-09-17/: bench-quick, sim-after-20-audio.json, review briefs/outputs). A run that 'failed' could not have produced these.

09-18: genuinely failed, left nothing. No commits after 09-17, no 2026-09-18 receipt dir, clean tree (only the long-standing untracked pnpm-lock.yaml), no ticket claims/comments dated 09-18.

So both rows are 'true' at different layers: 09-17 is a dispatch-layer status misreport (same family as today's 09-19 computer_asleep_or_app_not_running skip, which is being re-run as manual-catchup-20260919); 09-18 failed for real before writing anything. The dispatch-layer misreport itself lives in the scheduler, not this repo — leaving open for the owner.