Assert what this release changed, and say when the index pointer is behind

[Sunrisepeak]

tools/sandbox-closure.sh is the only thing in this ecosystem that resolves
published packages — every workflow substitutes its siblings' working trees.
openkal-musl 0.6.0 answered three defects reported as
openkal-linux#13, and
none of them was among the things the closure's program asked.

Three observations, each red on the previous release

a redirection reaches the started program: true
an uncaught exception ends on SIGABRT: true
asking without waiting returned true times, then named it: true

• a redirection the caller performed reaches the started program. It used not
  to: openkal spells inheritance as a handle of zero, and dup2 rebinds the C
  library's own table rather than the running program's stream.
• an uncaught exception ends on SIGABRT. It used to reach musl's
  a_crash() — hlt on x86_64 — and be reported as a segmentation fault. That
  is this ecosystem's own exit path: libc++abi's terminate handler ends in
  abort.
• asking after a started program without waiting for it returns.

⭐ The program it starts is itself, with an argument, rather than /bin/sh.
A criterion that shelled out would be asserting something about the sandbox, and
would report the absence of a shell as a defect of the release.

⚠️ And a preflight, because the first two runs failed for a reason that had nothing to do with the release

mcpp-index publishes a content-hash artifact and a rolling pointer. A client
fetches the pointer from raw.githubusercontent.com, which serves a cached
copy for some minutes after a push — so a run started right after a merge
resolves the previous artifact:

E_NOT_FOUND: package 'openkal-llvm-runtime@0.3.1' not found in the synced index
  (… mcpplibs@artifact:d19b7d0 …), synced 0 seconds ago
the index is current, so this name is either wrong or not published yet

Both of those sentences are false, and the report reads as a release that failed.
I checked the whole publishing path before finding it.

Removing the local index directory does not touch it, and neither does removing
mcpp's own registry — both were tried. What distinguishes "not pushed" from
"cached" is a route that does not go through the same cache:

gh api repos/xlings-res/mcpp-index/commits --jq '.[0].commit.message'
  → chore: update mcpp index pointer (1677798)     ← already pushed
curl raw.githubusercontent.com/.../mcpp-index-pointers.json
  → "index_version": "d19b7d0"                     ← what a client sees

That comparison is now made before an hour of building is spent answering
about the wrong index. Measured: the raw host caught up five to nine minutes
after the push.

Also

The mirror is an argument, defaulting to what a runner outside China wants; a
machine inside it passes mirror=CN.

Verified

Run to completion against the published set, from a frozen copy of exactly this
script:

compiler-runtime  compiler-rt    (openkal-llvm-runtime@0.3.1, graph)
kernel-abi        openkal        (openkal-linux@0.6.0, graph)
c-abi             musl           (openkal-musl@0.6.0, graph)
c++-abi           libc++         (openkal-llvm-runtime@0.3.1, graph)
…
the closure holds: published packages, resolved from the index, built and run