sdlc/ci: supply-chain & toolchain hardening; scheduled jco-browser and canary jobs

[lann]

The project rides pre-stabilization ABIs end to end (wasmtime -W component-model-async=y, Node JSPI behind a flag, a wit-bindgen 0.57/0.59 split where the 0.57 pin tracks an undocumented internal of wasip3 0.7), and its toolchain pins are largely aspirational. For a crypto project, supply-chain gating should exist before the dependency tree grows.

• Supply-chain gating: no cargo audit/cargo deny (or npm equivalent) in CI; no dependabot/renovate config. (Migrated from TODO.md.)
• npm ci, not npm install (scripts/setup.sh:74, 76): lockfiles are advisory today, and jco ^1.26.0 — the release containing the heap-corruption fix the README's Findings section hangs on — is a floating caret.
• setup.sh pins are aspirational: every install is guarded by have <tool>, so whatever is on PATH wins and no version is ever verified; the cargo-binstall bootstrap is curl | bash from a mutable main ref (setup.sh:46-47). Verify installed versions against the pins; pin the bootstrap. (Header doc also omits the WAC_VERSION/WASMTIME_VERSION overrides.)
• SHA-pin GitHub Actions (checkout@v5, setup-node@v4, rust-cache@v2 are tag-pinned; node-version: 24 floats across 24.x, where JSPI behavior can shift).
• Lockstep the wasmtime CLI and crate: setup.sh pins wasmtime-cli 47.0.1 while the crate floats within "47" (Cargo.lock resolves 47.0.2). For a pre-stable ABI these should match exactly.
• Scheduled non-gating jco-browser conformance job with Chromium, so browser conformance regressions surface without anyone remembering to run just conformance-jco-browser. (Migrated from TODO.md.)
• Bleeding-edge canary job: scheduled, non-gating build against the latest wasmtime/wit-bindgen/jco releases so ABI breakage is a notification, not an ambush during feature work. (Migrated from TODO.md.) Consider a scheduled timing-lab run alongside it (timing-lab: fixed-vs-random seal probe is not random; lab never runs in automation #31).

[lann]

The jco-browser CI item is resolved by #39 — in a stronger form than asked: the target now gates in CI (the Actions runner ships Chrome ≥137, so JSPI needs no flags) rather than running as a scheduled non-gating job, with local runs opt-in via CONFORMANCE_BROWSER=1. Checkbox ticked.

Still open here: supply-chain gating (cargo audit/deny, npm equivalent), npm ci in setup.sh, setup.sh version verification + pinned binstall bootstrap, SHA-pinned Actions, wasmtime CLI/crate lockstep, and the bleeding-edge canary job.

[lann]

Status note after #64, which touched this issue's territory without closing any of its boxes.

Moved in this issue's direction:

• Build provenance now has a precedent here. The toolchains release assets carry actions/attest-build-provenance attestations, because Publish the componentize-js toolchain; build the WPT runner every run #64 makes CI-built binaries part of the trust path (previously the published WPT components were built out-of-band and uploaded by hand, with no provenance at all). Whatever this issue settles on for release artifacts should extend that rather than invent a second scheme.
• CI dropped contents: write. The publishing job lived in ci.yml; it is gone, and the workflow is contents: read throughout. Write permission is now confined to the toolchain workflow, which is the only thing that publishes.
• One fewer floating input. scripts/wasm-tools.version was removed and the pin returned to a literal in setup.sh — relevant to the "setup.sh pins are aspirational" box, which still stands: every install remains guarded by have <tool>, so whatever is on PATH still wins.

Added surface for the SHA-pinning box:

• .github/workflows/componentize-js-toolchain.yml uses actions/checkout@v5 and actions/attest-build-provenance@v2, both tag-pinned like the rest. It also git clones and builds a third-party repository at a pinned SHA, then publishes the result as a release asset — worth an explicit line in whatever policy this issue lands on, since it is the one place the repository produces a binary from source it does not control.

[lann]

#90 added the first new runtime dependency this repository has taken since these boxes were filed, which makes it the first test of the gating they ask for — and it went in without any of it.

wasmtime-impl now depends on mea = \"0.6\" (its only dependency, slab, was already in the tree via wasmtime), replacing a hand-written admission queue with mea::semaphore::Semaphore. The evaluation was done by hand: 1.76M downloads in 90 days, 32 dependants including OpenDAL and foyer, one maintainer, pre-1.0 so minor bumps may churn the API. That is a reasonable basis for a decision and no basis at all for a policy — nothing in CI would have objected, and nothing will notice if a future version of it, or of anything below it, acquires an advisory.

Concretely, against the boxes here:

• Supply-chain gating — a cargo audit/cargo deny job would now have something to say about a 0.x dependency on the crypto host's critical path, and there is still no dependabot to tell us when it moves.
• SHA-pinned Actions / verified setup.sh pins — unaffected, still open.

Also worth recording next to the npm ci box: mea is pre-1.0, so "0.6" permits 0.6.x but not 0.7. Cargo.lock pins the exact version, and CI builds from the lockfile, so the floating range is bounded in practice — the gap is that nothing reviews the movement, not that the range is loose.

[lann]

#342 pinned the cargo-binstall bootstrap by version and digest (the curl | bash half of the third checklist item). The other half — verifying installed versions against the pins when have <tool> short-circuits — remains, as does the header-doc omission of WAC_VERSION/WASMTIME_VERSION.