fix(release): reject mislabeled binary artifacts before install

[ArjunDeshwal]

Summary

• Embed a versioned { product, version, target } identity in every compiled CLI.
• Make the npm launcher verify that identity after extraction and before it replaces the cached binary.
• Bound the identity process by time and output size, classify failures, clean staging files, and report validation telemetry.
• Keep the identity path independent of the UI, tree-sitter, authentication, and network initialization.
• Assert the compiled Freebuff identity in public CI.

Why

Issues #932, #1082, and #1143 report official platform archives launching unrelated bundled scripts instead of Freebuff. The public build script names a fixed entrypoint, while the launcher previously trusted any executable found under the expected archive filename.

This adds an end-to-end invariant at the consumer boundary: an artifact labeled freebuff-<target> is installable only when the executable identifies itself as the requested Freebuff version and target. A bad update cannot replace a working cached binary.

This is deliberately a defense against release/artifact mix-ups; it does not claim a root cause inside the private release service.

Validation

• bun test cli/src/__tests__/build-identity.test.ts cli/src/__tests__/release/artifact-identity.test.ts cli/src/__tests__/release/wrapper-safety.test.ts — 31 pass
• bun run build:sdk && bun freebuff/cli/build.ts 0.0.0-ci
• Compiled binary reports the exact expected identity from an otherwise empty environment
• bun cli/scripts/smoke-binary.ts cli/bin/freebuff — tree-sitter initialized and the login prompt was detected during the 10-second boot smoke
• Adversarial coverage: wrong product, version, target, schema, unrelated script, missing executable, malformed JSON, oversized output, timeout
• Integration coverage: a local release server serves a mislabeled tarball; the cached binary and metadata remain unchanged
• node --check cli/release-core/launcher.js
• bunx prettier --check on all changed source, test, and workflow files
• Public CI workflow parses as valid YAML

Scope

No backend, production probing, release-host mutation, or checksum/security claim. The contract detects accidental or stale artifact substitution; it is not intended as a cryptographic authenticity mechanism.

Rollout note: publish every target archive built with this identity contract before, or atomically with, the launcher version that enforces it. An older archive without --print-build-info will be rejected and a working cached binary will be retained.

Addresses the failure class reported in #932, #1082, and #1143.

This is a solid, focused fix for a real failure class (mislabeled/stale release archives clobbering a working cached binary). A few things stand out as well done:

• cli/src/entry.ts handles --print-build-info before importing tree-sitter, terminal, or auth code, so the identity path can't be broken by unrelated startup failures.
• readStagedBinaryIdentity/validateStagedBinary in release-core/launcher.js bound the check by time (buildIdentityTimeoutMs) and output size (BUILD_IDENTITY_OUTPUT_BYTES), kill the child on overflow/timeout, and classify failures with distinct error codes that flow into trackUpdateFailed.
• The test suite (artifact-identity.test.ts, build-identity.test.ts, updates to wrapper-safety.test.ts) covers the adversarial cases you'd want: wrong product/version/target/schema, an unrelated script, missing executable, malformed JSON, oversized output, and a hung process, plus an end-to-end 'server serves a mislabeled tarball, cache stays untouched' integration test.

Concerns a maintainer will need to weigh before porting:

1. Rollout ordering is a real operational hazard: every target archive needs to ship with --print-build-info support before (or atomically with) the launcher that enforces it, or all installs on that target break. You call this out in the PR body, which is good, but it means this can't just be merged — the release pipeline has to be coordinated with it.
2. The check only guards against accidental/stale substitution, as you note — it's not a substitute for signing. Worth making sure that's understood downstream so it isn't mistaken for a real integrity guarantee.
3. It's a large diff (529 lines, 9 files) touching a security-relevant path (the update/launcher flow) from a first-time contributor; expect it to need a careful line-by-line pass on the private side even though the mechanism itself looks sound.

No out-of-scope paths are touched. The idea and implementation are good; the size and rollout coupling are the main reasons this needs a real maintainer review rather than a quick merge.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.