feat(release): add native mc-host payload packages

[ahrav]

Summary

• add exact platform-filtered native payload package shells
• generate payload manifests, trust index, and genesis stop provenance
• enforce payload-before-parent ordering without publishing

Stack

PR 5 of 10. Base: stack/mc-host-04-client-policy.

Validation

• payload builder and trust-contract tests
• package metadata and size-budget checks

Post-Deploy Monitoring & Validation

No packages are published by this PR. During target qualification, watch payload digest, package size, platform floor, and staging validation failures; block promotion on any mismatch. Owner: release maintainers.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

buildProductionPayloads calls requireQualificationEvidence(rootDir) purely for its throw-if-unqualified side effect, then unconditionally calls fail(...) right after regardless of the outcome. That means once release inputs actually become production-qualified, this function will still always throw ("no assembly path is qualified yet") with a misleading message, since nothing here branches on the qualification result. If a future PR flips production_qualified to true without also revisiting this function, bun scripts/build-mc-host-payload.ts (no flags) will keep failing closed for the wrong reason instead of proceeding to build. Worth a // TODO tying this to whichever follow-up ticket implements the real assembly path, so it's not forgotten.

[claude]

Review summary

This PR adds the three native mc-host platform payload packages (darwin-arm64, darwin-x64, linux-x64-gnu), the payload builder/validator script, and the fail-closed trust-index + genesis stop-provenance artifacts. Overall this is careful, well-tested release-engineering infrastructure. Highlights:

Strengths

• Security-conscious supply-chain design: payload packages explicitly forbid preinstall/install/postinstall lifecycle scripts and any dependencies/bin fields, and this is enforced by validatePayloadPackageDir + covered by tests. No lifecycle-script supply-chain vector here.
• Exact-pinned optional dependencies ("0.38.0", no ranges/tags/workspace specifiers) in the parent packages' optionalDependencies, enforced by validateParentManifests. Avoids dependency-confusion / semver-drift risk.
• Fail-closed by default: every trust-index entry ships qualified: false, published: false, null digests, since production inputs aren't qualified yet — matches the PR description ("no packages are published by this PR") and is verified in release/mc-host-payload-index.json/mc-host-n-minus-one-stop.json.
• Strong path/byte integrity checks: assertSafePayloadPath blocks traversal/absolute/non-payload-rooted paths, verifyPayloadDir rejects symlinks and unlisted files and verifies exact size+sha256 per file. Good defense-in-depth for a pipeline that will eventually stage native binaries.
• Extensive test coverage (scripts/build-mc-host-payload.test.ts) exercises drift detection, traversal/symlink/duplicate-path rejection, size-budget overflow, Synapse-claim mismatches, and stop-provenance edge cases (self-authored, N-2, reservation versions, modified predecessor manifest).
• No binaries or tarballs are committed anywhere in packages/mc-host-* — consistent with the "no packages published" claim.

Minor finding (left as an inline comment)

• buildProductionPayloads (scripts/build-mc-host-payload.ts:1131) calls requireQualificationEvidence and then unconditionally fails afterward regardless of the result. Once inputs are actually qualified in a future PR, this will keep failing closed with a stale/misleading message unless someone remembers to revisit it — worth a tracking TODO.

Non-blocking observations

• None of the new release:payload / release:payload:check scripts (nor the pre-existing release:contract:check / release:qualify:check) appear wired into CI yet, so drift in the committed trust artifacts wouldn't be caught automatically until a later stack PR presumably adds that gate.
• runCheck/--check hardcodes expectedPredecessorVersion = null (genesis-only), which is correct for this first payload-bearing release but will need updating once a real N-1 predecessor exists — flagging for stack-PR awareness, not a defect here.

No security or correctness issues that block this PR; it does exactly what the description says (shells + fail-closed trust artifacts, no publish).