fix(ding): release vanished archived FIFO ownership

[schickling-assistant]

Problem

A staged DING notice can remain the FIFO head after its inbox message is archived, even when a maintained adapter later proves that the exact owned payload is no longer retained. Later unread messages then receive no transport while the target and sidecar remain healthy.

Goal

Release only an archived staged head after positive maintained-adapter absence, then advance later FIFO work without re-pasting the vanished notice or weakening fail-closed handling.

Decisions

• Add NotRetained as positive evidence from a maintained adapter that successfully parsed the live composer. Missing, unreadable, unrecognized, and timeout evidence remains Unproven.
• Keep receipt classification separate from queue policy. flush_pending releases NotRetained only for an archived message or recovery notice.
• Keep unread and adopted notices staged after NotRetained, preventing a later fresh re-paste. RetainedBlocked and Unproven remain staged.
• Preserve the initial transport, retry backoff, two-observation Return gate, and persistence model unchanged.

Verification

• Test-first red: the focused Ding suite exited 101 because ReceiptState::NotRetained and PokeOutcome::NotRetained did not exist.
• Changed-file rustfmt --check: passed.
• cargo test --lib ding::tests::: 30 passed, 0 failed.
• cargo test --test invariants: 1 passed, 0 failed.
• Immutable reproduction baseline 8f112ebe: RED; accepted-receipt control: GREEN.
• Exact candidate 701d3db archived-only E2E: GREEN. The initial recovery transported once with zero acceptance; after A was archived, a healthy Codex NotRetained receipt released A and B transported and was accepted exactly once.
• Independent exact-head review: APPROVED with no blocking findings. A fresh detached dev4 clone passed 30 Ding tests, the invariant test, changed-file formatting, and diff checks.
• Four adversarial mutations were RED in their intended tests: broad unrecognized-to-NotRetained, unread release, archived retention, and RetainedBlocked release.
• Full-tree format is inherited red: base and candidate normalized output have the same SHA-256, 3b6f2ef927cee59bc8ead6219b6059b65da5362292850a3f7c480f091bf2de23.
• Full strict clippy is inherited red: base and candidate report the same eight unrelated warnings outside Ding.
• Full tests are inherited red in the remote Nix environment: base and candidate both fail only tests/materialize.rs:700 because its subprocess cannot find git.

The regression tests prove that archived positive absence advances message B exactly once without re-pasting A; unread positive absence keeps A staged and B at zero; unknown and retained-blocked evidence keep B at zero.

Complexity

One receipt variant and one queue-policy branch; no new dependency, file, transport, timer, persistence layer, or abstraction boundary.

Concerns

NotRetained is only as sound as each maintained adapter's live-composer parser. Screens that cannot be located or parsed remain Unproven, preserving the fail-closed boundary.

Friction & bottlenecks

The current Nix devshell's full-tree rustfmt proposes inherited unrelated formatting changes. The four changed Rust files pass formatting, and the full-tree base/candidate output is byte-identical after normalizing checkout paths. Strict clippy and the full test suite also have causally matched inherited failures described above; neither failure touches Ding.

Follow-ups

Durable or replayable staged ownership remains out of scope. The harness-neutral adapter seam overlaps with #123 but is not reworked here.

References

Closes #151

Reproduction: https://github.com/schickling-repros/2026-08-st2-staged-fifo-head-blocking/tree/8f112ebe0b96632fc57d2222b808955a9bbdac60

Refs #123

[schickling]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 701d3dbc09

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".