fix(native): rank an unset specificity slot the same however it is spelled

[YevheniiKotyrlo]

Problem

specificityCompareFn answers 0 for two rules that are not equally specific once the sheet has reached a device.

A specificity array is sparse, and getNativeInjectionCode (src/metro/injection-code.ts) injects the sheet with JSON.stringify, which writes each hole as null:

.inp              ->  [1, 1]
.inp::placeholder ->  [2, 1, null, null, 1]

The comparator branched on the raw slot and returned a normalised difference:

if (aSpec[Important] !== bSpec[Important]) {
  return (aSpec[Important] || 0) - (bSpec[Important] || 0);

undefined !== null, so it answered 0 - 0 at a slot neither rule sets. The runtime sort in src/native/styles/index.ts then leaves the two rules in className order, so className="inp inp-ph" and "inp-ph inp" cascade differently. Any rule carrying a pseudo-element or an !important declaration can trigger it.

Solution

• Every slot is ranked with spec[slot] || 0 before it is compared, so a hole, a null and a 0 are one unset component — Selectors 4 §16 counts an absent component as zero.
• SpecificityValue admits null, because that is what a native runtime reads. The two compile-time merges in selector-builder.ts read a slot by its type instead of !== undefined.

Why it isn't caught today

registerCSS injects the compiler's own object, where both sides are holes, so every existing test compares undefined with undefined. The compile-time sort in src/compiler/stylesheet.ts runs the same comparator over that in-memory form, which is why only the runtime sort is exposed.

Tests

• src/__tests__/native/specificity.test.tsx compiles .inp / .inp::placeholder, asserts the compile-time order, puts the rules through the same JSON.stringify round trip, asserts a null arrived, and sorts them with the runtime comparator from both input orders. It also pins each slot alone, against every slot beneath it, and an unset slot spelled as a hole, null or 0 on either side.
• src/__tests__/vendor/tailwind/states.test.tsx does the same with Tailwind's own output for text-red-500 placeholder:text-blue-500 and text-red-500 selection:text-blue-500.

On main, the 7 new cases that carry a null or a 0 into a deciding comparison fail with Received: 0 and pass with the fix; the other 15 pass on both.

Verification

On Windows with Node 26: yarn lint clean · yarn typecheck clean · yarn test --maxWorkers=2 --coverage 1070 passed, 21 skipped, 3 failed — the two babel suites that fail identically on f70c402 · yarn build clean · yarn example expo export --platform web clean · nothing unstaged after either build. Coverage of src/utilities/specificity.ts is 100% of lines and branches. Not run: the iOS dev build, which no file in this change reaches.

No existing issue tracks this — searched the tracker for specificity, specificityCompareFn, placeholder order, className order and null specificity.

Merge order

It shares lines with #459 (compiler/selector-builder.ts, utilities/specificity.ts); whichever lands second rebases.

Base

Cut from f70c402. It merges cleanly into main (a5002c5), where the new cases fail before the fix and pass after it.

[YevheniiKotyrlo]

No device frame

The description's assertion is the evidence: after the JSON round trip a device's sheet goes through, main's comparator answers 0 for .inp and .inp::placeholder, so their order follows the className order.