#90 residual: records separable only through broken-typed fields collide → order-dependent counter; hash couples to typeToString text #141

Follow-up to #90 (PR #140), from the PR review. Low severity — the primary #90 goal (no churn across compiler versions / unrelated edits) holds for the general case and is verified byte-identical on TS 5.9 → 6.0.3.

Residual 1 — under-discrimination of broken-typed fields

structuralSig normalizes every unknown/any/opaque/review field to the same token, so two DISTINCT records separable only through broken-typed fields hash identically and fall back to an order-dependent counter (…2) — a narrow slice of the churn #90 targets.

• Real case: base-ui menuStoreV1x8ec / …2 (differ only in rootMenuStore… vs triggerMenuStore…, both → string).
• The PR Fix #90: derive stable-name hash from structure, not type.id (no churn across versions/edits) #140 refinement (base + t.text in the sig) fixed base-ui but regressed blend 0 → 2 counters (selectMenuGroupType2, selectMenuItemType2), which are structuralSig-EQUAL entries (sort can't stabilize equal keys). So the churn class moved rather than disappeared.

Residual 2 — hash couples to typeToString

The t.text discriminator is TS's typeToString output, which is version-sensitive (e.g. intersection-member order {a}&{b} vs {b}&{a} could canonicalize on a major bump). Verified stable across 5.9 → 6.0.3, but latent risk for names distinguishable ONLY by broken-field text.

Proper fix (deferred — bigger/riskier)

Merge entries whose FULL structuralSig is genuinely identical (they're structurally interchangeable → one name, refs redirect). Needs care around the add-only seen diamond-collapse (Rcyc), which could otherwise make two genuinely-different entries look equal → unsound merge. Would fix both base-ui and blend and drop the counters entirely.

Meanwhile

Counters here are STABLE across the 5.9 → 6.0.3 transition (deterministic sort), so no active churn today; this tracks closing the residual properly.