release: package visibility 404 strands immutable manager tag

[sixtoad]

Defect

The first real coherent release after #85/#87 published the immutable multi-architecture manager tag, then failed while making the new GHCR package public:

#43 pushing manifest for ghcr.io/sixtoad/leash-manager:native-v0.3.4@sha256:b2c03d7acf8b... done
INFO: Docker tags created ...
gh: Not Found (HTTP 404)

scripts/release.sh invokes:

gh api --method PUT "/user/packages/container/leash-manager/visibility" -f visibility=public

After the failure, both package endpoints resolve and report the package as private. No GitHub release or Git tag was created. A normal retry is then refused because the immutable manager tag exists, so the verified manager-first pipeline cannot recover without deleting or overwriting an immutable artifact.

Exact state

• source commit: ea0d7df5ca7b5a9e1265dfe3ef742438d8011d38
• requested release: native-v0.3.4
• manager: ghcr.io/sixtoad/leash-manager:native-v0.3.4
• manager index digest: sha256:b2c03d7acf8b34645b4a91b14394f6fbea84a7d177a99a1f746e2ddb2e81f746
• runnable children: linux/amd64 and linux/arm64
• package API visibility: private
• GitHub release/tag native-v0.3.4: absent
• no Walk workload or credential was involved

Expected

The release uses the supported package-visibility operation and can safely resume after manager publication without deleting, retagging, or overwriting the immutable manager.

Acceptance

• use the correct GitHub Packages API method/endpoint for an authenticated user-owned container package
• bound and clearly diagnose visibility mutation/verification
• verify anonymous pull before CLI stamping/release creation
• add an explicit safe resume path for an existing manager tag when the Git tag and GitHub release are absent
• resume only after deep verification of the existing index: exact required platforms, distinct child manifests, architectures, full source revision, release version/channel, and manager contract labels
• resolve and embed the existing immutable digest; never push, delete, mutate, or retag it during resume
• refuse resume on any provenance, platform, label, contract, tag, or release mismatch
• focused tests cover fresh publication, visibility failure, matching resume, mismatched resume, and existing Git tag/release refusal
• the real native-v0.3.4 recovery completes from the existing digest and publishes matching CLI archives/GitHub release

Blocks completion of native-v0.3.4 and the Leash #78 full Walk/BME/Codex ACP dogfood.

[sixtoad]

Implementation review corrected the visibility assumption before any live mutation.

GitHub's current REST Packages documentation exposes get/list/delete/restore operations, but no supported package-visibility update endpoint. GitHub's visibility documentation directs personal-account packages through Package Settings → Change visibility. Reported PATCH /users/{owner}/packages/... attempts return the same 404 as the failed PUT used by the release.

References:

• https://docs.github.com/en/rest/packages/packages
• https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#configuring-visibility-of-packages-for-your-personal-account

The accepted implementation direction is therefore fail-closed and supported:

1. Never call an undocumented visibility mutation endpoint.
2. After first publication, query authenticated package state. If private, halt immediately with the exact Package Settings URL and resume command.
3. Resume only after authenticated metadata reports public and an anonymous digest pull succeeds.
4. Preserve the existing manager digest and perform no push/delete/retag during resume.
5. Independently prove registry-tag absence on the fresh path; package API 404 is not evidence of tag absence.

This matches the currently stranded native-v0.3.4 state and provides a safe recovery after the one-time visibility checkpoint.

[sixtoad]

Post-merge dogfood found a remaining blocker before any live mutation.

The stranded manager was published from release source commit:

ea0d7df5ca7b5a9e1265dfe3ef742438d8011d38

PR #89 merged the recovery tooling at:

799b091d121fd5cf0cb0530486dbb3be278068ac

The merged scripts/release.sh still sets COMMIT=$(git rev-parse HEAD), verifies the existing manager's OCI revision against that current commit, and stamps the CLI/manager revision from it. Consequently, running the documented command from merged walk-integration would require the stranded manager to claim revision 799b091...; it correctly claims ea0d7df..., so the real recovery cannot pass.

This is not a reason to weaken provenance or stamp the recovery-tool commit onto older runtime source. Safe recovery needs to separate:

• the trusted recovery tooling revision (current merged head), and
• an explicit clean release-source checkout pinned to the already-published manager revision.

Required follow-up:

• recovery accepts an explicit source root/checkout only in resume mode
• source root must be a clean detached or pinned Git checkout whose full HEAD equals the manager revision
• recovery helper/verifier comes from the merged tooling checkout, while manager verification, CLI builds, embedded entrypoint/BPF inputs, E2E, and release target come from the pinned source checkout
• fresh publication refuses any source-root override
• tests reproduce tooling HEAD != manager/source HEAD and prove artifacts/target use the source revision without copying or modifying it
• the real native-v0.3.4 resume uses a clean ea0d7df... source checkout and the merged recovery tooling

The GHCR package remains private and unchanged; no GitHub release exists.