fix(release): pin collation on the manifest hashes

[justinjoy]

Closes #1294. Two release gates hashed a sorted file list and compared the
result against a pinned or committed value, with the collation unpinned.

The defect is live on the GA path, not latent

run-downstream-matrix.sh is invoked from release-tag.yml:279, so its
manifest check gates GA. glibc's en_US collation ignores the hyphen in
Method-Modifier.facts, moving it after MethodHandleConstant.facts. On a
runner with a non-C locale the manifest differs and the gate fails with

DOOP dataset manifest <x> != pinned <y>

— which reads as dataset tampering. The worst available message for the actual
cause.

Verified against the real dataset, not reasoned about

Downloaded the zxing dataset through bench/data/doop/download.sh (archive
checksum confirmed) and computed the manifest both ways:

C      215ddcc50bca70c0089e0ced9298274aec4edb6741736d03cc3c4386b96f831c
en_US  472346fb234ac0610e2a0b83b7076e8279525aeeade628261fd98433d54d62b6

The committed oracle is the C-order value, so pinning is corrective rather
than a re-baseline.

The other five workloads were checked the same way before touching anything —
cspa-fast, galen, polonius, ddisasm, crdt all reproduce their
committed oracles under C and are collation-invariant. That check was the
precondition: pinning a sort whose oracle came from a different collation would
convert an intermittent failure into a permanent one, and would look like
silently re-baselining a security-relevant hash.

C is also the only collation a committed hash can safely depend on — it is byte
order and invariant, whereas en_US collation is not stable across glibc
versions (2.28 rewrote it), so an en_US-derived oracle is pinned to a moving
target.

The guard

check-manifest-collation.sh lifts the two manifest functions out of
run-downstream-matrix.sh with sed rather than retyping them, so unpinning
either one in that script makes the test fail. A retyped copy would assert only
that GNU sort honours an explicit LC_ALL=C prefix — a coreutils property
nothing here can break. The perf gate's manifest is an inline expression and
cannot be lifted, so a static pin check covers that site.

Between the three review gates, 12 mutations, 12 caught, each with its own
message: unpinning either function, unpinning or removing the perf-gate sort, a
partial rewrite to --zero-terminated with the sibling still pinned, a plain
unpinned sort added beside a pinned one, a renamed or deleted function, an
unparseable body, and a truncated extraction that parses but returns nothing.

That last one is worth flagging to reviewers: the guard passed three earlier
revisions while a truncating } would have left it comparing two empty strings.
Both the review and risk gates found it independently.

Operator note

WIRELOG_DOOP_DATASET_MANIFEST_SHA256 has no committed value anywhere in this
repository, so any existing pin is out-of-tree. Its owner must recompute it
under LC_ALL=C — otherwise this change flips that runner red.

Also: "C == en_US today" for the five non-discriminating workloads is an
accident of their filenames, not a property to rely on elsewhere.

Follow-up

#1297 — the perf gate's manifest embeds the directory path it is given, so
relative, absolute and trailing-slash forms yield three hashes from one dataset:
the same tampering-shaped message from a second cause. manifest_for_doop is
immune because it strips the prefix with sed, so the two computations have now
drifted twice — on collation and on path handling — which argues for one shared
helper taking the downstream matrix as reference.