Release standard: add witness + scry wasm gates, crates.io/npm, rivet verification extraction

[avrabe]

Sweep finding: meld fuses wasm in/out but runs no wasm-level verification and has 0 rivet verifies links (traceability lives in safety/requirements/traceability.yaml, ~20 refs, not in the rivet graph). Track A is fully signed.

Track C — wasm gates (priority):

• Add a witness MC/DC gate on fused components.
• Add a scry abstract-interpretation gate.
• sigil-sign the fused wasm — blocked on friction: wsc can't sign its own wasm32-wasip2 output — blocks org-wide sigil-sign-wasm standard sigil#164; cosign now.

Track B — distribution: GH-Release-only.

• Publish to crates.io; add npm wrapper if meld-cli is user-facing.

Track E — rivet extraction: migrate the traceability.yaml refs into typed rivet verifies links + an executable gate (relay is the test-level exemplar). The existing LS-regression verification-gate.yml is a good base.

---

Part of the org-wide release-consistency campaign — the five-track standard is in the release-artifact-pipeline skill (plugin v0.10.0).
Coordination hub: pulseengine/pulseengine.eu#98 — if this standard does not fit this repo (you need a deviation, different sequencing, or want to sync on how a track applies), raise it there. Deviations are decided in the open at the hub, not diverged silently.

[avrabe]

Triage (issue-hunt) — Track E == #303 (and it's not mechanical); Track C has a hard blocker

Digested against meld's actual state. Sequencing/deviation notes for the campaign hub (pulseengine.eu#98):

Track E (rivet verifies extraction) is the same work as #303 — and #303 shows it can't be a mechanical migration. This issue's premise ("migrate the ~20 traceability.yaml refs into typed verifies links") assumes the refs are sound trace that just lives in the wrong file. They aren't: rivet validate reports 180 errors / 0% requirement-coverage, no test/verification artifact type exists in the loaded schema, and requirements like SR-33 link only to GitHub issues (derives-from #94), not to any real STPA artifact. So "extract to verifies links" first requires: adding a verification artifact type to the schema, and authoring the missing left-side derives-from links (a safety-modeling judgment, see #303). I filed #303 with the full remediation plan; Track E should be tracked as #303 and is gated on the maintainer's STPA judgment calls there — not a quick win.

Track C (wasm gates):

• witness MC/DC + scry gates on fused components are real and doable, but are CI integration of those tools (non-trivial; new workflow wiring).
• sigil-signing is blocked on friction: wsc can't sign its own wasm32-wasip2 output — blocks org-wide sigil-sign-wasm standard sigil#164 (per the issue itself); cosign-now is the interim.

Track B (crates.io/npm): a release/publish decision, maintainer's call.

Net: no part of #302 is an ungated autonomous win right now — Track E ⊂ #303 (judgment-gated), Track C signing is blocked on sigil#164, Track B is a publish decision. Happy to take any track once the maintainer points at it / #303's modeling calls are made. Raising the Track-E-is-#303 coupling at pulseengine.eu#98 so the campaign sequences meld realistically.