Ingest musl where the upstream publishes it (the layer half of #175)

[avrabe]

varve#196: the rolling layer still ingested -linux-gnu for every Linux
payload, including for tools whose release already publishes a static musl
build. This is the layer half of the varve#175 decision.

It was not expressible before varve v0.39.0, which made asset-for values
template-expanded (pulseengine/varve#199).

What changes

tool	version	musl
synth	v0.75.0	already published
ordeal	v0.22.0	already published
meld	v0.58.3	already published
varve-producer	v0.38.0 → v0.39.0	v0.39.0 is varve's first musl release
varve-serve	v0.38.0 → v0.39.0	same

Every asset name was checked against the actual release listing, not inferred
from the pattern.

The key stays the gnu triple

host_platform() resolves every Linux host to {arch}-unknown-linux-gnu, so a
musl-keyed payload would match no host and fail closed. A triple here is a
platform key, not a libc claim — the same shape pulseengine-wasm already
uses for wac.

What the repo's own checker caught

check-manifest.py refused the first version of this:

FAIL: pulseengine/varve is pinned at 2 releases (v0.38.0, v0.39.0)
      — one release's assets would be checked against another's sums

varve-core (crate) and varve-core-api (docs) are also sourced from
pulseengine/varve and had to move with the tools. Good gate.

What this does NOT do

It does not lower the layer's floor. Portability is the maximum floor
across payloads, and rivet, spar, witness, loom, kiln and wsc still ship gnu
only — so a consumer on RHEL 9 or Alpine still cannot run the toolchain. That
needs the remaining upstreams: rivet#980, spar#447, witness#234, sigil#279,
loom#388, kiln#514.

Five of eleven is progress worth depositing, not a fix to announce.

🤖 Generated with Claude Code

https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu

[avrabe]

Security: added ordeal v0.22.0 → v0.22.1 to this branch.

ordeal published GHSA-xfxf-qxr3-435x (HIGH) today. Every release from
0.2.0 through 0.22.0 — including the v0.22.0 this layer pins — mis-encoded
shifts and rotations at non-power-of-two bit widths, returning Unsat with
an LRAT certificate that re-checks. The checker certified the CNF it was
handed and the CNF was the wrong encoding, so the usual defence ("we do not
trust the solver, we check the certificate") does not catch it.

This matters more here than in any single repo's CI: a layer is how the
organisation distributes a prover. Consumers pinned to 2026.09.16 have the
affected build now.

v0.22.1 publishes the same four Linux assets, so the musl mapping in this
branch is unchanged, and check-manifest.py still passes.

Two things this PR does not do, both needing the realm key:

1. A line-status advisory. This is exactly what REQ-ADVISORY-002 and the
   known_problems / yanked fields exist for — the already-published
   2026.09.16 carries the affected ordeal, and a re-issued line-status reaches
   consumers without a new layer. Depositing a fixed layer does not retract
   the one people are already pinned to.
2. Deciding whether 2026.09.16 should be yanked or merely carry a known
   problem. A yank is the stronger statement and it is the maintainer's call.