feat(release): publish one owner-issued capability and conformance manifest

[drewstone]

Problem

Downstream products currently ask Runtime to publish consumer-specific check names and artifacts (UP-*, product-specific matrices, bespoke release proof). That scales as N consumers × M capabilities, couples Runtime's CI vocabulary to each product, and rewards producing more checks rather than stronger execution semantics.

The useful requirement underneath those requests is real: a consumer must be able to determine, from an exact packed Runtime release, which durable/control capabilities were actually exercised and what evidence supports the claim.

End state

Publish one Runtime-owned, versioned, content-addressed conformance manifest for each release candidate and release.

The manifest should identify:

• package name/version, source commit, build identity, schema version, and exact first-party cohort;
• owner-named capabilities such as retained admission, replay cursors, interaction acknowledgement, cancellation acknowledgement, native continuation, context transfer, recursive observation, and cleanup settlement;
• for each capability: supported | unsupported | unproven, the exact conformance scenario, result digest, evidence/artifact references, and execution environment;
• packed-tarball digest and the command/tool version that verified it;
• any live prerequisite that was unavailable, represented as unproven rather than silently narrowed into a pass.

A small verifier should check the manifest, evidence digests, package identity, and cohort identity without importing workspace source.

Consumers map their own labels onto Runtime capability keys locally. Runtime never learns Braid's UP-* names or any other product's release checklist.

Architectural constraints

• No second runtime, scheduler, evidence store, or release state machine.
• The manifest is generated from the existing native conformance tests and packed-package verification.
• A capability claim is derived from behavioral evidence, not from the presence of a method or type.
• Missing evidence fails closed as unproven; it does not make package installation fail unless a consumer explicitly requires that capability.
• Release checks remain few and owner-shaped. New behavior extends the manifest vocabulary rather than adding another family of consumer-named jobs.

Acceptance

1. A packed Runtime candidate emits one deterministic manifest plus referenced evidence.
2. Re-running against identical package bytes emits the same digest.
3. Mutation tests prove that changing package bytes, cohort identity, scenario output, or evidence bytes invalidates verification.
4. At least retained run control, interaction response acknowledgement, replay, cancellation, context continuation, and recursive observer behavior are represented.
5. A clean consumer installs the packed cohort, verifies the manifest, and selects required capabilities without workspace links or ignored peers.
6. Existing downstream-specific release-artifact requests can be deleted or reduced to local mappings.

This supersedes consumer-specific release check naming such as #748 while preserving the underlying proof requirement in a reusable form.

[drewstone]

Shipped in PR #923, merged as ba623e6d. Recording exactly which acceptance criteria this closes and which two need a downstream step, so nobody has to re-derive it.

1. A packed candidate emits one deterministic manifest plus referenced evidence — met. publish.yml passes --report to the cohort step, then emits and verifies agent-runtime-conformance-manifest.json after the pack step and uploads it in the same artifact as the .tgz. Measured locally against a real archive and a real cohort (interface 1.3.0, eval 0.150.2, knowledge 8.0.10, runtime 0.143.1, sandbox 0.31.0): digest 6588d9af466bff6b4a50fccc1bd5e0129d6d65743002e8f2a0dc25736ca1d4a6, 6 supported and 2 unproven.

2. Identical package bytes emit the same digest — met. Two full emissions back to back on an unchanged tree produced byte-identical manifests. Durations, timestamps and run ids never enter the manifest. An earlier pair differed in exactly one field, package.sourceCommit, because a commit landed between the runs.

3. Mutation invalidates verification — met. scripts/conformance-manifest.test.mjs (9/9) covers changed package bytes, a mismatched archive identity, changed cohort identity, a scenario result rewritten inside the manifest, a status promoted with a recomputed digest, changed evidence bytes, a declared case absent from the run, and digest stability. Proven live too: one appended byte on the real tarball gives ::error::packed archive sha256 … does not match the manifest, exit 1.

4. The capabilities are represented — met, with two honestly unproven. retained-run-control, session-replay, cancellation-acknowledgement, native-continuation, recursive-observation and cleanup-settlement are supported. interaction-response-acknowledgement and context-transfer are unproven and stay that way until behavioral evidence exists: today only the interaction refusal path is covered (the acknowledged response and its replay are not), and no test drives a portable context between environments. Neither is narrowed into a pass.

5. A clean consumer installs the cohort, verifies the manifest, and selects required capabilities — partially met. The verifier imports no workspace source and was run against the packed archive, the cohort report and the evidence tree; --require context-transfer fails closed with ::error::required capability context-transfer is unproven, exit 1. What was not exercised is that same verification from inside a fresh consumer install — verify-packed-cohort.mjs already proves the clean-install half separately. A consumer that wants the end-to-end path in one run should say so and it becomes a step in that job.

6. Downstream-specific release artifacts can be reduced to local mappings — downstream action. The manifest gives Braid and other consumers the keys to map UP-* onto; deleting those requests belongs in the consuming repositories, not here.

Two notes for whoever extends this. The capability-to-test map, conformance/capabilities.json, is the one hand-authored file — everything downstream of it is mechanical, and a case name that no longer matches a test keeps its capability unproven rather than passing (that happened during this work and is why one capability was briefly unproven). Canonical serialization and hashing come from the published @tangle-network/agent-eval, so there is exactly one canonical-JSON owner; do not add a second.