asset-for may be a template, and a shim that could only be a copy is refused

[avrabe]

Two changes, both from the musl switch meeting reality.

1. asset-for values expand like any other template

synth v0.74.0, ordeal v0.21.0 and meld v0.58.3 now publish musl, and the
layer should ingest those for its gnu platform keys — which is exactly what
asset-for is for. But its values were used verbatim, and these upstreams
put the release tag in the asset name:

synth-v0.74.0-x86_64-unknown-linux-musl.tar.gz

A literal entry survives until the realm's scanner bumps the version
unattended — then the manifest names a release that no longer exists and the
deposit 404s at 3am. An upstream shipping musl under a versioned name was
not expressible at all.

synth-%R-x86_64-unknown-linux-musl.tar.gz now follows the bump.

Backwards compatible by construction: every existing entry — wac-cli-…,
wsc-linux-x86_64, wrpc-wasmtime-… — carries no placeholder and expands to
itself. That has its own test, so this cannot quietly break three realms.

(%R, not %V: these assets carry the release tag; %V is the bare
version. The first draft of the test asserted the wrong one and was corrected
against the real release listing rather than guessed twice.)

2. shim install refuses where the shim could only be a copy — DD-031

A shim is the varve binary under another name: argv[0] dispatch, no
parser, arguments as raw bytes, one process. On unix it is a symlink, so
self-update replaces the binary and every shim follows — the code comment
says precisely that.

On Windows there is no symlink to rely on, so it was a copy, and the
property inverts silently: the copy binds to the varve that existed at install
time, self-update never touches shims, and every shim keeps running the old
code forever.

The subtle part: the pin still resolves the right layer, so the tool
dispatched is correct. What goes stale is varve's own verification and
refusal logic — the worst thing to have quietly out of date in a tool whose
job is refusing the wrong bytes.

So it refuses, explains why, and names varve run (which resolves the pin per
invocation and is never stale). The replacement mechanism is deliberately
open — DD-031 records all four candidates and what each costs:

candidate	cost
.cmd wrapper → varve run	reintroduces a parser, two processes, batch quoting
hard link	orphaned by self-update's atomic replace
Windows symlink (Dev Mode)	freshness varies per machine
shell functions	make and CI get the ambient binary, not the pinned one

Shipping the easy one now would entrench the weaker model before any Windows
build exists (varve#197).

cmd-shim.md also stops telling readers "on Windows a copy" — behaviour no
build has ever produced, in a repository that gates this class of claim
elsewhere.

Verification

The refusal branch was type-checked by compiling it under cfg(all())
once and reverting — the real target cannot be used here because ring's C
build will not cross-compile to MSVC from macOS. shim_platform.rs keeps it
honest afterwards, since nothing on unix would notice a fs::copy coming
back.

Both new guards negative-controlled: restoring the copy fails; re-adding the
documentation promise fails.

fmt · clippy -D warnings · 1044 tests, 0 failed · trace-gate OK.

🤖 Generated with Claude Code

https://claude.ai/code/session_019TNtfRjLNhEz82G2ggeeNu