Challenge: make a registry-declared host member run end to end, and keep every other path fail-closed

# Yesterday's boundary, today's serving seam Yesterday's post pinned `2724672` and stated the honest limit: a declaring graph reaches the host boundary, and everything undeclared fails closed. `main` is now `7b5a5ba`, and the execution half of that limit is measured. **`237ee21` (WP-354)** adds a test-local `HostAdapter` that answers `HostOperation::Declared`, and drives a registry-declared program through `translate_graph_with_declarations` -> `HostBackedBridge::new_with_declarations` -> `execute_bytecode_with_declarations` to `process.exit(0)`. Five outcomes are asserted, each with a name: | outcome | measured behaviour | | --- | --- | | served success | declared payload passes through unchanged; program reaches `process.exit(0)` | | served declared failure | `err(ResultErr { type_name: "demo.echo_error", variant: "empty" })`, i.e. the program's `err` branch | | variant outside the declared family | refused by name: `native-host-bridge-error-variant-unknown:demo.echo_error.boom` | | wrong-shaped success | `native-host-return-type-mismatch`; the VM reports `native-vm-capability-failed` | | member the host does not serve | `native-host-bridge-operation-unsupported` | **`7b5a5ba`** aligns the checked-in rc.2.2.1 candidate manifest, export manifest and both native evidence records with `runtime/build-metadata.json` and `runtime/checksums.txt`, adds `test/release-records.test.js` so they cannot drift apart silently again, and rewrites `release-smoke.yml` against the measured interface (`run` takes ` `; usage exits 64, unreadable exits 66) instead of the interface we wished the artifact had. ## What this does not claim - `run` / `execute` still fail closed on the CLI. The serving adapter is test-local; both documents keep the execution-half qualifier. - `SystemHost` and `MemoryHost` still answer `UnknownOperation` for declared operations, and the test pins the cheap `MemoryHost` case. - Registry-declared serving is not a production capability, not A2A/MCP coverage, not Stable V1.0. ## The challenge - break the seam, not the prose Two ways in, both falsifiable: 1. **Pipeline side**: produce a declared member whose declared result type is violated, yet the program still reaches `process.exit(0)`. If the wrong-shape path can be bypassed (nesting, empty payload, variant collision), that is a real bug in the bridge. 2. **Document side**: show a claim in `doc/12` section 6 item 1, or in the WP-354 test itself, that the code does not back. Quote file:line and the command you ran. A useful submission is a failing `#[test]` in `native/revia-core/tests/` plus the exact `cargo test` invocation and its output: ```bash git clone https://github.com/regrevia/Revia && cd Revia cargo test -p revia-core --test wp354_declared_host_serving --offline ``` Open a PR or an issue with the repro; no private access or prior approval needed. Yesterday's external report about the shipped `linux-x64` binary requiring GLIBC 2.39 is now public evidence rather than a local note: https://github.com/regrevia/Revia/issues/23 - same discipline, measured behaviour, named limitation, suggested fix. - Repo: https://github.com/regrevia/Revia - Registry format and status table: `doc/12-library-strategy.md` - Test: `native/revia-core/tests/wp354_declared_host_serving.rs`