fix: harden resumable discovery lifecycle integrity

[Charlie-Wang-03]

Summary

This PR hardens runner-v2 branch discovery as a resumable workflow rather than relying on prompt-level assumptions about state integrity and object uniqueness.

It also keeps the existing Moonshine integration baseline update (72a64f8 → bb0e4aa) in this PR. The PR originally contained only that one-line pin update; before review, the related discovery reliability work was consolidated here to avoid creating another small upstream PR and to validate the final runner changes against the current Moonshine runtime in one reviewable milestone.

Problem

The discovery workflow persisted enough state to resume work, but several invariants were not machine-enforced:

1. Discovery rows could contain an unknown status and still load.
2. One discovery ledger could contain the same object name more than once under case differences.
3. A row marked verified could still load after its published archive was deleted or changed on disk.
4. "Do not select a previously attempted object" was primarily a prompt policy. A new discovery could submit an exact prior verified or failed object name to the acceptance gate.

Those gaps can make a resumable run's ledger disagree with the actual artifact set or allow duplicate work to be accepted as new discovery.

Contract

For branch discovery, the runner now fails closed on these deterministic invariants:

• every persisted row has a known lifecycle status;
• named rows are unique within a discovery ledger under case-insensitive exact-name comparison;
• status == "verified" implies that the bound archive exists and its content still matches the persisted SHA-256;
• a new discovery may not reuse an exact case-insensitive name already recorded as verified or failed in prior runner state;
• repairing the existing failed row through --retry-failed remains allowed.

The duplicate contract is deliberately exact-name only. It does not claim semantic alias detection.

Implementation

Discovery state validation

load_or_create_state() now validates:

• the explicit discovery row status set;
• per-ledger case-insensitive object-name uniqueness;
• existence/readability/content hash of every verified discovery artifact.

Duplicate-safe new discovery

A shared _ensure_discovery_name_unattempted() guard checks the existing attempted-object ledger before accepting a newly discovered object.

The guard is applied at the relevant new-discovery boundaries:

• before the discovery verification provider is invoked;
• when an accepted verifier result is published/recovered;
• when the legacy ARCHIVE_PROPOSAL fallback materializes a discovered object.

The ordinary non-discovery verifier path is unchanged, so --retry-failed can still repair the original failed row rather than being mistaken for a new duplicate discovery.

Current Moonshine integration baseline

The exact integration pin is advanced from:

72a64f8984e0e7e1b0a50f6e53e4d00e4fffbb7d

to current Moonshine main:

bb0e4aa025fdcc5297fff1025ab4876f120ed615

The workflow remains commit-pinned for reproducibility.

Deterministic reproduction

The audit was established before the production fix.

Expanded negative-control run 34361711235 failed on both Python 3.9 and 3.11 because the pre-fix runner did not reject:

• unknown discovery row status;
• case-insensitive duplicate discovery names;
• missing verified archive;
• tampered verified archive;
• a previously verified exact object name submitted as new discovery;
• a previously failed exact object name submitted as new discovery.

The positive controls in the same suite already passed for:

• an intact verified archive;
• an unattempted new object;
• the existing non-discovery failed-repair path.

Verification

Fork validation after the fix:

• offline regression run 34362129168: 27/27 passed on Python 3.9 and Python 3.11;
• pinned Moonshine integration run 34362129186: 7/7 passed on Python 3.11;
• current-Moonshine validation run 34362539327: 7/7 passed using exactly bb0e4aa.

The consolidated PR head (12992a56) was then revalidated by upstream GitHub Actions:

• upstream offline regression run 34362788841: success;
• upstream Moonshine runtime integration run 34362788749: success.

No real LLM/API credentials, Tavily calls, or MCP network behavior are required for these regressions.

Scope / limitations

This PR does not:

• attempt semantic alias/equivalence detection between mathematically related names;
• introduce a new state schema version;
• change mathematical verification policy;
• add automatic retries or new Moonshine runtime behavior;
• modify archive content.

The intended guarantee is narrower: persisted discovery state and accepted exact-name discovery remain internally consistent, artifact-bound, and fail-closed across resume.