Select runtime build variants exactly

• A program linked, for each runtime unit, the matching variant with the most conditions, with ties broken by id. A unit whose builds are keyed on two features and had no build for both would have linked a build missing one of the program's defines, with no error.
• selectRuntimeVariant now takes the one variant whose conditions name exactly the features the program has among those the unit's builds are keyed on. A pack with no such build, or with two, fails the build: runtime pack has no build of scr_bytes.c for this program's features: the unit's builds are keyed on fileHandle, staticLink, textDecoderLegacy, the program has fileHandle, textDecoderLegacy, and exactly one variant must name exactly those (the pack builds default, legacy, fileHandle, static).
• The manifest format is unchanged, and every combination exists today, so no program selects a different object.

The invariant is now checked

tests/harness/runtime-variants.test.ts runs the real selector over every matrix (the shared one per object format, its library-only form, and macOS), every flavor's unit list and every combination of the features that select a unit or one of its builds:

• each combination selects exactly one build, and that build names exactly the combination;
• its defines are the union of the single-feature builds' defines;
• every feature a build is keyed on is a member of NativeLinkFeatures or RuntimeFeatureSet, since a name no program can have would never select its build.

A combination no program can have needs no build: runtimeFeaturesImpliedBy reads off the rule table which features always come with another (every formdata. call is also a web body), and the test skips a combination that has a feature without one it implies. Worker combinations are skipped only where the compiler refuses workers before selecting (library flavors, wasm), and the test asserts those are the flavors without worker builds. Removing one combination from the matrix, misspelling a feature and dropping a define from a combined build each fail it.

packages/runtime-pack-common/test/runtime-pack-matrix.test.ts had its own copy of the old selection rule; it now calls the compiler's.

The case this is for

#3040 (WeakRef) and #3053 (function member properties) each add a build column to scr_json.c and list their own combinations. Each is green alone. On a merge of main, this PR and both branches as they were:

• the merged branches' own matrix tests pass;
• this PR's test fails in all nine matrices: release scr_json.c with fnMemberProps+weakRef;
• a program with a WeakRef and a function member write is refused: SC3003: runtime pack has no build of scr_json.c for this program's features: … the program has fnMemberProps, weakRef …;
• with main's selector the same program links the fn-member-props build, without SCR_WEAK_REF.

Both PRs now add their column as a twin of every existing build, and the same merge passes the test and runs the program as Node does. The test also passes on the fleet's integration tree (main plus 34 open PR heads).

Proof

• Zero-cost gate with --gate-corpus=all against 714482d49 (first commit; the second adds one exported function and test code): PASS, 5,176 identical, 96 fail on both sides, no differing row. Bench geomean -0.05% [-1.13%, +1.14%], self -1.39% [-1.91%, +0.25%], fixtures +0.34% [-0.19%, +0.87%].
• The selector compiled natively answers as it does under Node (tests/harness/self-hosting-runtime-pack.test.ts), and the candidate compiler builds its own source.
• packages/compiler/src/backend, packages/runtime-pack-common/test, packages/compiler/src/native/sanitizer.test.ts, pnpm lint and pnpm format:check pass.

The macOS jobs that fail here (6125-constants-module.cjs, 8830-process-report-island) fail the same way on other open PRs that run them; pushes to main skip those jobs.

🤖 Generated with Claude Code