feat(extension): build provenance stamping for verifiable binaries

[gennadiryan]

Important

Problem

The Amicode webview ships a vendored opencode fork, and builds get verified on a remote GUI that is not the build machine. Before this change, "this binary is the fix" was a claim with no evidence: nothing in the artifact tied it to a branch, a commit, or a build-time tree state — so a stale or misconfigured build could pass (or fail) a verification and nobody could tell which.

Approach

Stamp every built binary at build time with its provenance — branch, commit, and dirty-state — and expose it in the shipped artifact's metadata. A verified build then answers "which binary was actually tested" from the artifact itself, making remote verification attributable to exactly the reviewed code.

Approaches Considered

• Embed provenance at build time (chosen) — the stamp is written by the build itself, so a wrong or dirty tree is recorded, not hidden.
• Derive provenance at runtime from the environment — fails exactly when it matters: on a machine that is not the build machine.
• Record provenance out-of-band (release notes, CI logs) — not attached to the artifact, so an unattributed binary can't be checked after the fact.

Scope

• In: the build-time stamping step, its test coverage, and the artifact metadata surface where the stamp is exposed.
• Out: any change to the vendored fork's behavior; the fork-side attachment fix this work exists to verify is a separate change and separate repository.

---

What changed

• The dev-build entrypoint now stamps branch, commit hash, and dirty-state into the built artifact at build time.
• The stamp is surfaced in the shipped artifact's metadata (the .buildinfo surface), readable without network access.
• The build-provenance test suite covers: correct branch and commit recorded, dirty tree flagged, and a clean build not flagged.

Verification

• Test suite for the stamping step passes (correct branch/commit, dirty-state detection).
• Exercised end-to-end by the image-attachment fix verification: the retested binary's stamp matched the fork branch fix/image-attachments at commit 42a2c2a82, dirty: false at build time.

Key Decisions

• The stamp is written at build time only; runtime reads of it never re-derive the values.
• Branch name, commit, and dirty-state are the fixed set: enough to answer "which code", nothing that invites drift.

Constraints & Invariants

• No change to the fork's behavior or to the webview runtime.
• The stamp's presence is required for any verification claim about a shipped build; builds without a stamp are not attributable.

Source

Companion to the fork-side attachment fix: harmoniqs/opencode PR #140 from branch fix/image-attachments (commit 42a2c2a82), whose verification this work made attributable. Recorded in the amicode issue for image attachments and their blob-scheme resolution.

Notes

The stamp is a guarantee, not a diagnostic: it cannot fix a bad build, it can only prove (or disprove) that the build being verified is the one under review. The image-attachment fix was the first consumer; any future fork change inherits the same discipline.