test(registry): qualify Zig packages against a real native consumer

Addresses the outstanding part of #248. The hashing fix itself is already on main — dd38b897d replaced the sha256+1220 scheme with real zig fetch hashing on the day the issue was filed, and kept the artifact digest separately as artifactSha256. What was missing is the last clause of the ask: "add a clean native Zig consumer to qualification."

Verified before writing anything

Checked against reality, not just the code: the live registry serves craft-0.0.387-HIz1ixywQgEYmYLr_6M5JlT59rPQc07VrNPqk8UBQc8h, and a real Zig 0.18.0-dev.146 consumer independently computes that exact string. So the contract also holds across compiler versions — the registry hashes with managed 0.17.0 — and a clean consumer with the advertised .url/.hash exits 0.

Legacy versions keep their 1220… hash and validateZigHash still accepts that form, which is the compatibility the issue asked for rather than an oversight.

Why this test, and why it would have caught the bug

Every existing Zig hash assertion compares the registry against itself, so a wrong-identity hash satisfied all of them. This one publishes through the real /zig/publish route and then hands the advertised artifacts to the compiler:

• zig fetch on the served tarball must print exactly the advertised hash;
• zig fetch --save must record that hash and URL in a consumer's build.zig.zon — the step that originally failed;
• the hash must not be a 1220 digest.

Three things a reviewer should know

1. It needs the managed toolchain. computeZigHash requires zig version to equal 0.17.0 exactly. Without it every publish in this file returns 503 — 8 of its 10 tests already failed that way on my machine before this change, which is environmental, not a regression. I downloaded 0.17.0 and ran the file against it: 15/15 across zig-routes.test.ts and zig-native-hash.test.ts.
2. The compiler must be spawned asynchronously. The registry under test serves the tarball from the same process, so Bun.spawnSync deadlocks the pair until the 130s timeout. I hit this; the comment in the test records it.
3. An unexplained thread, deliberately not folded in. Fetched as a dependency rather than hashed directly, the fixture resolves to Zig's N-V-__8AAK… placeholder identity despite having a complete manifest (name, version, fingerprint, paths) — so zig fetch and zig build --fetch disagree on it, while the genuinely published craft package is fine under both. That is why this asserts via fetch --save. It may be nothing more than a fixture quirk, but it may be a real edge for packages whose manifest Zig won't parse as a dependency, and it deserves its own issue rather than a footnote in this one.

🤖 Generated with Claude Code