Pin varve v0.41.0 — so this layer finally states the libc its payloads need

[avrabe]

Measured 2026-10-08 against the published layer: 2026.10.5 carries 57 payload
layers and NOT ONE states a libc. Every tool in this realm is glibc-only, so
the layer cannot start on RHEL 9, Debian 12, Alpine or distroless — and nothing
in the layer says so. A consumer discovers it by running a binary and reading a
loader error (varve#175).

The v0.39.0 assembler pinned here has nothing to state it with. From v0.40.0 a
Linux payload carries eu.pulseengine.platform.libc, measured from the
payload's own PT_INTERP rather than declared — and the deposit refuses a
declared value the staged bytes contradict, so it is a measurement and not a
claim.

v0.41.0 rather than v0.40.0 because it is the current release and brings nothing
this realm must avoid: its provenance change affects only upstreams that attest
per asset, and every payload here is ingested from a cosign-signed
SHA256SUMS.txt (rung 1), which that code path never touches.

No payload, version or platform changes. The next deposit produces the same
layer contents, with the libc floor recorded for each Linux payload.

varve v0.41.0 is published and verified: cosign verify-blob OK on
SHA256SUMS.txt and gh attestation verify exit 0 on the archives, with both
probes negative-controlled — a one-byte flip makes each of them refuse.

🤖 Generated with Claude Code

https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu

[avrabe]

Correction to a number in the PR body. The conclusion stands; the count was wrong.

I wrote "2026.10.5 carries 57 payload layers and NOT ONE states a libc." 57 was
the outer OCI manifest's layer count — envelope + signed manifest +
line-status + the payloads — not the payload count, and I had also been reading
layers[].annotations rather than the signed index's manifests[].annotations,
which is where eu.pulseengine.platform.libc actually lives.

Re-measured at the right level:

pulseengine 2026.10.5 — payload entries: 54
  libc: {'(none)': 54}

So 54, not 57, and still zero stating a libc. The reason for the pin bump
is unchanged.

For contrast, wasm-layers 2026.10.0 — the first layer deposited with the v0.41.0
assembler — shows what this repo's next deposit should look like:

wasm-layers 2026.10.0 — payload entries: 54
  libc: {'static': 32, 'glibc': 8, '(none)': 14}

The 14 with no libc are exactly the 14 macOS payloads: Mach-O has no
PT_INTERP, so there is nothing to measure, which is correct rather than
missing.