Publish attested preview and stable Pylon Prime releases

[rynfar]

Problem

Deterministic fork tarballs still need a protected publication and promotion path. The fork intentionally removed upstream release automation because it targets main/v*, depends on upstream R2 credentials, advances mutable channels, and uploads with --clobber. Restoring that workflow would violate the fork's product-branch and provenance boundaries.

Required publication model

Use GitHub Releases in pylon-code/prime-agent with no external package or storage credentials:

• A protected pylon push publishes a prerelease preview for the exact merged source, using a Pylon-only tag such as pylon-build-g<sha12>-r<recipe>.
• A manual workflow dispatched from refs/heads/pylon promotes an existing preview to a monotonic stable tag such as pylon-stable-000001-g<sha12>-r<recipe>.
• Stable promotion references or copies the exact preview digests. It never rebuilds.
• Existing tags/assets with different bytes fail. Never use --clobber.
• Ignore main, inherited upstream v* tags, PR heads, and arbitrary refs.
• Stable admission verifies the source is reachable from protected pylon, required exact-SHA checks are green, and preview attestations are valid.

Provenance and permissions

• Pin every action by commit.
• Build jobs use contents-read only.
• Only the publisher receives contents-write and it does not execute downloaded artifacts or repository source.
• Only the attest step receives id-token: write and attestations: write.
• Use keyless GitHub/Sigstore build provenance for every tarball and preview/stable manifest.
• Verification must bind subject digest, issuer/Rekor inclusion, pylon-code/prime-agent, exact signer workflow/ref, source commit/tree, and recipe id.
• Publish signed monotonic preview/stable channel manifests. A feed pointer may advance but every referenced build release and asset is immutable.

Acceptance coverage

• preview creation is idempotent for identical bytes and refuses changed bytes;
• stable promotion reuses all preview digests and advances one monotonic sequence;
• wrong ref/repository/workflow/source/check/result/attestation fails closed;
• inherited tags and main never publish;
• workflow permissions are least privilege and no repository secret is required;
• gh attestation verify documentation plus automated negative tests cover tamper, replay, wrong signer, and wrong subject;
• preview and promoted stable install into temporary prefixes on Ubuntu and macOS; WSL2 consumes the Linux artifact. Native Windows Prime install/runtime is deferred until upstream support exists.

Scope and dependencies

Depends on #28's deterministic artifact contract. This issue owns publishing, keyless attestation, channel promotion, rollback/yank runbooks, and workflow governance only. It does not add a Pylon installer or updater.

Coordinate with #1 and Pylon #114. Do not restore upstream .github/workflows/build-binaries.yml. Comet and #20 are not dependencies.

[rynfar]

Read-only implementation audit complete. No repository setting, file, tag, release, attestation, or publication was changed.

One concrete blocker must be fixed in #29: protected pylon currently requires Check changelog fragment, but that workflow runs only on pull_request. A stable admission routine that honestly requires every branch-protection context on the exact merged source SHA would therefore always fail. The #29 PR should add a pylon push proof job that asserts the canonical repo/ref, resolves the associated merged PR, verifies its head check came from GitHub Actions app id 15368 and succeeded, then emits the required context on the merged SHA. It must not relabel a PR-head check as an exact merged-SHA check or silently omit a protected context.

The smallest sound implementation is:

• protected preview publication only after the canonical pylon push aggregate and Ubuntu/macOS/Windows deterministic-install gates succeed;
• immutable prerelease pylon-build-g<sha12>-r<recipe> with the four tarballs, build manifest, deterministic preview manifest, and keyless build-provenance attestations for all six subjects;
• manual pylon-ref stable promotion that downloads and verifies an existing immutable preview, checks every exact-SHA protected context and attestation, runs the same bytes through three-OS install gates, and publishes only a signed stable manifest under monotonic pylon-stable-NNNNNN-g<sha12>-r<recipe>;
• no rebuild, clobber, mutable release edit, npm/R2 credentials, arbitrary refs, main, inherited v*, or repository-source execution in the publisher;
• rollback/withdrawal as a higher signed stable sequence with an append-only revocation list, never release/tag deletion.

Ordering remains strict: merge #32 first; create #29 from the resulting latest origin/pylon (not PR #32's current head); configure immutable releases plus guarded pylon-preview/pylon-stable environments and full-SHA action policy before #29 merges; then verify the first preview and dispatch stable sequence 000001 as explicit maintainer checkpoints. No repository secret is required.

Admin prerequisites do not exist yet: the repository currently has zero environments/releases/deployments, and the release-immutability setting was not exposed by the read-only REST probe. The publisher must require immutable:true after publication and fail loudly otherwise. The first live preview remains a maintainer verification gate.

[rynfar]

Admin prerequisites advanced after #32 merged:

• repository immutable releases are now enabled and read back as enabled: true (enforced_by_owner: false);
• GitHub Actions remains enabled with the existing allowed_actions: all policy, but full-SHA pin enforcement is now enabled and read back as sha_pinning_required: true;
• a pre-change scan found zero non-40-hex action references in current workflows.

No environment, release, tag, deployment, attestation, or publication was created. pylon-preview and pylon-stable environment policies remain pending the final reviewed job boundaries.

[rynfar]

Maintainer approved the solo-maintainer environment model. Admin prerequisites are now complete:

• pylon-preview: required reviewer rynfar, self-approval allowed, only custom deployment branch pylon;
• pylon-stable: required reviewer rynfar, self-approval allowed, only custom deployment branch pylon.

Both environment and branch-policy API responses were read back exactly. This is the deliberate single-maintainer exception: each deployment still requires explicit approval, but prevent_self_review cannot be enabled until a second maintainer exists. No deployment, release, tag, or attestation was created.

[rynfar]

Publication tag governance is now configured and read back:

• repository ruleset 21950766, Pylon immutable publication tags;
• active for refs/tags/pylon-build-* and refs/tags/pylon-stable-* (including sequence reservations);
• blocks all tag updates and deletions;
• no bypass actors; API read-back reports current_user_can_bypass: never;
• new tag creation remains allowed so the protected publisher can atomically create the next reservation.

I first attempted to restrict creation with GitHub Actions app 15368 as the sole bypass. GitHub rejected that configuration because its global Actions integration is not part of the repository or owner-organization ruleset source. I did not add a broad maintainer/owner bypass. This configuration instead preserves the key invariant: once any publication or sequence tag is created, neither the publisher nor a maintainer can update or delete it without an explicit governance change.

No tag, release, deployment, or attestation was created.