test(rfc64): bind release CLI into the M1 runtime manifest

[branarakic]

Impact

This is proof/build hardening for the M1 canary; it does not change synchronization policy or live node behavior.

The M1 launcher starts release-shaped DKG CLI daemons, but the clean runtime manifest previously began at @origintrail-official/dkg-agent. That meant the actual packages/cli/dist/cli.js entrypoint was outside the hashed evidence closure. This PR makes the CLI package the clean/build root and includes packages/cli/dist in the deterministic runtime manifest.

The expanded clean build exposed an existing incremental-build defect in packages/mcp-dkg: its clean script removed dist but retained tsconfig.tsbuildinfo, allowing TypeScript to emit nothing on the next build. The clean script now removes both.

Before

sequenceDiagram
    participant L as M1 launcher
    participant B as Clean build
    participant D as DKG CLI daemon
    L->>B: clean/build Agent dependencies
    B-->>L: manifest excludes packages/cli/dist
    L->>D: execute packages/cli/dist/cli.js
    D-->>L: process is outside hashed entrypoint closure

Loading

After

sequenceDiagram
    participant L as M1 launcher
    participant B as Clean build
    participant M as Runtime manifest
    participant D as DKG CLI daemon
    L->>B: clean/build CLI and M1 sync dependencies
    B->>M: hash packages/cli/dist plus dependency closure
    L->>D: execute packages/cli/dist/cli.js
    D-->>L: release entrypoint is bound to reviewed source

Loading

Clean-build repair

sequenceDiagram
    participant C as packages/mcp-dkg clean
    participant T as TypeScript build
    C->>C: remove dist and tsconfig.tsbuildinfo
    C->>T: rebuild from a genuinely clean state
    T-->>C: emit dist deterministically

Loading

Validation

• Actual CLI-rooted clean + build from zero — pass
• Runtime manifest: 686 hashed files; packages/cli/dist/cli.js present
• Gate 2 runtime/completeness unit lane — 32/32 pass
• Gate 2 TypeScript project — pass
• M1 selective-coverage unit lane — 73/73 pass
• M1 TypeScript project — pass
• git diff --check — pass

[otReviewAgent]

🔴 Bug: Adding the CLI to the clean manifest does not prove the CLI was executed

What's wrong
This change adds packages/cli/dist to the clean-build snapshot, but the execution check still only requires the agent, chain, core, and storage entrypoints. Clean-build files are compared only if the child actually loaded them, so a process can pass provenance without loading any CLI artifact. That makes the new release-CLI provenance claim accept a direct agent process rather than proving the release CLI ran.

Example
A child process that loads packages/agent/dist/index.js, packages/chain/dist/index.js, packages/core/dist/index.js, and packages/storage/dist/index.js, but never loads packages/cli/dist/cli.js, still passes assertGate2ExecutedRuntimeMatchesBuildV1. Expected behavior for this PR’s release-CLI provenance claim is that missing CLI execution should fail.

Suggested direction
Require the CLI entrypoint in executed-runtime validation when release-shaped runtime provenance is expected, or route the child launch through the CLI so packages/cli/dist/cli.js is observed by the loader hook.

For Agents
Look at runtime-provenance.ts and the child launch path in two-agent-harness.ts. Preserve the existing clean-build byte comparison, but make the release-shaped path prove the CLI entrypoint was loaded, or actually launch through the CLI so the loader hook observes it. Add a focused assertion that executed manifests without packages/cli/dist/cli.js are rejected when the CLI is in the runtime closure.

[otReviewAgent]

🔴 Bug: CLI provenance is only checked as a constant, not as loaded runtime evidence

What's wrong
The PR’s risky behavior is that the release CLI daemon entrypoint is now supposed to be cryptographically bound to the runtime provenance. The new test only asserts that a path string exists in the closure, so it would still go green if the verification path accepted runtime evidence that never loaded the CLI entrypoint. That gives false confidence for an integrity-sensitive change.

Example
A failing-test sketch: include { path: 'packages/cli/dist/cli.js', ... } in the clean build entries, build an executed manifest without that entry, and assert assertGate2ExecutedRuntimeMatchesBuildV1 throws. Today the added test would still pass because it never runs that scenario.

Suggested direction
Add behavior-level coverage for the new CLI entrypoint: prove the clean manifest includes CLI bytes and that executed-runtime verification fails when those CLI bytes are absent or changed.

For Agents
Look at devnet/rfc64-gate2-multi-asset-completeness/test/runtime-provenance.test.ts. Extend the manifest fixtures to include a CLI dist artifact and add a regression assertion that omitting the CLI loaded entry fails, preserving the existing agent/chain/core/storage checks.

[otReviewAgent]

🟡 Issue: Unify the CLI runtime build selector with the manifest closure

What's wrong
This change widens the build filter from the agent closure to the CLI closure, but the manifest closure remains a parallel, manually curated list. That is a structural drift point: the code now encodes the same concept in two different shapes, so future changes to the release runtime can silently update one side and not the other. The new test reinforces a string-level spot check instead of deleting the duplication.

Example
The CLI package depends on additional workspace packages such as @origintrail-official/dkg-mcp, adapters, dkg-epcis, dkg-okf, and dkg-node-ui, while the manifest closure here only adds packages/cli/dist on top of the old agent-centric list. Any future CLI dependency change has to be remembered in at least two places.

Suggested direction
Make the runtime package model the canonical abstraction: a single list of package names, dist paths, and exclusions should generate both GATE2_RUNTIME_PACKAGE_CLOSURE and the pnpm clean/build args. That would make this PR a one-source change instead of widening the build graph while relying on a manually curated manifest list.

For Agents
In devnet/rfc64-gate2-multi-asset-completeness/runtime-provenance.ts, preserve the current clean/build behavior and manifest schema, but derive the pnpm filters and package closure from one shared runtime-package model, preferably reusing or extending scripts/lib/runtime-build-plan.mjs. Add/adjust checks so the manifest package paths and build filters are produced from the same source of truth.