jobs: `job-dead-letter-retention` deletes `4 Missing` rows at 90 days, silently clearing their alert without triage

[radandevist]

Known-open item K-2 from the #852 design (§11). Flagged by the final remediation round.

The problem

R10-1's retention exemption was scoped (by captain steering) to bytes-possible rows — external_state_status IN (1, 6). 4 Missing is bytes-impossible, so it stays eligible for the 90-day failed_at sweep.

Missing is an integrity anomaly: it means prepared state that should exist does not. Deleting the row at 90 days silently clears its alert, with no triage and no record that anyone looked.

The implementer honoured the steering literally rather than widening the exemption unreviewed — correct call, filed instead.

Fix direction

Decide whether Missing requires acknowledgement before it becomes retention-eligible, or whether its alert history elsewhere is sufficient evidence. If acknowledgement is required, it needs an operator resolution path (see K-1 / #863).

Phase 3. Refs #194, #852.

[radandevist]

Owner decision (Radan, 2026-08-01)

Acknowledgement is required before a 4 Missing row becomes retention-eligible. Missing is an integrity anomaly; deleting it at 90 days with nobody having looked discards the only signal that something went wrong.

Sequencing consequence, recorded deliberately. #863 was decided as an automatic re-check, which cannot help here — Missing is already a definitive answer, so there is nothing to re-probe. That means no actor can currently acknowledge anything.

Agreed approach:

1. Ship the acknowledgement flag and the retention exemption now (schema + engine).
2. Ship the operator surface that sets it with the staff jobs dashboard (A5 — Staff job-visibility dashboard #636).
3. Add an alert on the count of unacknowledged Missing rows, so that if this class turns out not to be rare, we find out rather than assume. Between (1) and (2) these rows accumulate; the count alert is what stops that from becoming a silent second starvation class.