S4: CI cutover — release.yml builds from materialized tree, retire fork workflows (fork-absorption Phase 3) #1096

Sub-issue of #1091 (Phase 3). S3 (#1095) is closed — cross-compilation is proven. This is the riskiest slice — the actual cutover.

Design decisions

Build artifact sharing (avoids 7x CI time multiplier)

The binary is built once in a dedicated build-binary CI job. All binary-consuming jobs (fast, vsix-gate, app-shelf-boot-proof, boot-smoke, release packaging) declare needs: build-binary and retrieve the artifact via actions/download-artifact. This avoids 7 jobs each compiling independently (7 × 2-5 min = 14-35 min wasted CI time).

Pin verification replacement

The fork-era lock.repo && lock.tag && lock.ref provenance check is replaced by two checks:

1. lock.version matches the OPENCODE_VERSION string baked into the compiled binary (the binary already embeds this at build time).
2. The manifest's upstream_base_sha matches the base commit that was actually materialized into the overlay tree.

These are strictly local checks — no fork repo access required.

Channel assertion mechanism

The build:binary script records OPENCODE_CHANNEL into a .buildinfo sidecar file (plain text, key=value) alongside the compiled binary. The post-build assert_ui_gate.sh assertion reads this sidecar — simple, deterministic, no grepping minified code.

Acceptance Criteria

• A dedicated build-binary CI job compiles the binary once from the materialized overlay tree for all 3 platforms
• All binary-consuming CI jobs (fast, vsix-gate, app-shelf-boot-proof, boot-smoke, release packaging) use needs: build-binary + actions/download-artifact — no job compiles independently
• release.yml packages binaries from the shared artifact — no download from harmoniqs/opencode
• The package script invokes build:binary instead of fetch_opencode.mjs for binary provisioning
• A .buildinfo sidecar is written alongside the binary recording OPENCODE_CHANNEL; assert_ui_gate.sh reads it to verify dev channel
• The app-bundle-gate CI job verifies provenance: lock.version matches baked OPENCODE_VERSION, upstream_base_sha matches the materialized base commit
• Every CI job that called fetch:opencode instead declares needs: build-binary and downloads the shared artifact (with bun installed)
• The boot-smoke matrix (native execution on 3 platforms) passes with the new binaries
• prepare-release-candidate.yml and overlay-promotion-bot.yml are deleted
• promote.yml still dispatches release.yml correctly
• An alpha release through the full pipeline succeeds on all platforms
• After the alpha validates: OPENCODE_FETCH_TOKEN is removed from CI secrets (separate manual step)
• After the alpha validates: REPO_ACCESS_TOKEN is removed after verifying no remaining consumers (separate manual step)

Rollback path

Code revert and secret removal are separate, sequential steps — secret deletion is non-revertable.

• Code revert: One PR reverts the CI changes back to the fork-download path. The fork is still alive (not archived until S7) and the old release.yml is one git revert away. This is safe and repeatable.
• Secret removal: Happens only after the alpha release validates successfully on all platforms. This is a separate manual step precisely because it cannot be undone — re-creating secrets requires regenerating tokens with the correct scopes.

The ordering is: land code changes → validate alpha → remove secrets. Never the reverse.

Obligations (from #1091 review)

• O1: Verify promote.yml compatibility with the new release.yml
• O2: Keep boot-smoke matrix as native execution verification
• O4: Update the package script's internal fetch_opencode.mjs call
• O7: Specify how the lock-file pin verification step transitions between S4 and S6 — S4 replaces the fork-era check with the lock.version + upstream_base_sha verification described above; S6 restructures the lock file format itself

Risks

• Cross-compiled binaries may behave differently than natively-built ones — the boot-smoke matrix (native execution, not just compilation) is the safety net.
• CI time: compiling once is slower than downloading a pre-built binary, but the single-job + artifact-sharing design keeps the increase to one compile (~2-5 min) rather than seven.
• The package script chains multiple steps; updating one link may break downstream steps.
• Secret removal is irreversible — the explicit ordering (code first, secrets last, after alpha validation) is the mitigation.

Part of #1091. Answers #843 (retire fork provisioning, replace with overlay build).