fix: reconcile published releases without repeating npm publication

[davidahmann]

Outcome

npm published 0.7.1 successfully, but registry metadata appeared after the former
readback budget expired. The publish run stopped before GitHub Release creation.
This repair extends bounded reads and adds protected finalization of that known
publication without repeating npm publish or changing the tag or artifact.

Changes

• Allow twenty metadata reads thirty seconds apart; permanent identity conflicts
  still fail immediately. Exercise availability on the thirteenth read.
• Add a main-dispatched recovery workflow with the existing npm environment
  reviewer, no OIDC permission and no npm mutation command.
• Prove first-attempt candidate and publication identities, the successful npm
  step and the candidate actually consumed. Reject other publish attempts or an
  existing GitHub release, including drafts.
• Verify signatures, registry bytes and the full packaged canary before GitHub
  creation. Keep original source/publication identity separate from recovery.
• Retain minimal provider observations and a recovery receipt, with raw logs
  kept private. Clarify reconciliation versus withdrawal in the runbook.

Acceptance and authority

The owner's admission/evidence hardening instruction authorizes this repair and
completion of the verified publication. The source authority records candidate
run 35466952501 and publish run 35467443471. The latter remains failed evidence;
recovery does not rewrite it or claim publication ran again.

Validation

• Full native gate: 468 tests, coverage thresholds and package lifecycle passed.
• Exact structural audit passed all nine categories. Independent review found no
  material issues at ab85f15aa4ed9668394c01483b785afdf579f547.
• Real GitHub read-only observe/validate rehearsal passed against the original
  run, attempt-specific job records and artifact-download log bindings.
• The published npm package passed signature/attestation verification and the
  full registry-downloaded canary. Its bytes match the qualified candidate.
• These workflow/tooling changes produce the identical 0.7.1 tarball; no package
  code, version, dependency pin or release tag changed.

Limits

This first recovery path accepts stable tags, first attempts and a failed
postpublish metadata/signature step before any GitHub release effect. Existing
releases, unavailable retained candidate artifacts or uncertain effects block.
It grants no general release overwrite, publish retry or protection bypass.

Assistance disclosure

• Agent-assisted implementation and independent review.
• DCO sign-off included.
• No credentials, raw private logs or customer inputs included.