Preserve supported runtime rules when the browser rejects CSSOM nodes

Start with packages/runtime/src/layer.ts, host.ts, and core.ts, then reproduce the mixed manifest case in Chromium or WebKit. Read the existing correctness-regressions.test.ts case named “hydration rejects CSSOM nodes dropped by the browser” and add focused coverage for rejected nodes around supported rules. Done means supported 21px styling survives rendering, hydration, insertion, deletion, refresh, and fallback while mismatch checks remain strict.

Problem and classification

P1 · Required for the 2.0 freeze. A browser-rejected selector can prevent a later, supported rule from being inserted. Progressive hydration can consequently remove styling that was already working in the server-rendered page.

Parent: #445. Implementation detail of the rendering-equivalence work in #451; completion evidence feeds #454. This issue adds a newly reproduced counterexample, not another general rendering audit.

Baseline: 70444b18c8102fa7a9d811ec51ef96902573792c. Reproduced locally on 2026-09-27 in Chromium and WebKit. The new counterexample has not been run in Firefox. Concurrent local freeze documentation/tests are unrelated and must be preserved.

Reproduction and observed behavior

Use this public execution manifest with an element whose class is mixed:

const manifest = {
  version: 1,
  languageVersion: 3,
  utilities: [{
    id: 'mixed',
    name: 'mixed',
    type: 0,
    matchers: [{ type: 'static', name: 'mixed' }],
    emit: {
      type: 'static',
      rules: [
        { selector: '&:mastercss-unknown-pseudo', declarations: { color: 'red' } },
        { declarations: { width: '21px' } }
      ]
    }
  }]
}
const runtime = await MasterCSSRuntime.start({ manifest })
runtime.observe()

The engine correctly preserves both rules:

@layer utilities {
  .mixed:mastercss-unknown-pseudo { color: red }
  .mixed { width: 21px }
}

The existing correctness-regressions.test.ts case named “hydration rejects CSSOM nodes dropped by the browser” does not exercise a rejected node preceding a supported node in this multi-node output.

Cause and source evidence

• layer.ts increments offsets and node counts before insertion, using expected output node counts.
• host.ts continues with nativeIndex + nodeIndex after a failed insertion; deletion also assumes all expected nodes exist.
• core.ts requires browser node counts to equal engine node counts during hydration.

CSSOM permits parsing to fail and requires an index beyond the current rule count to fail separately.

Implementation plan

• Keep Rust rules, ordering, resource ownership and generated CSS unchanged. Do not restore host-support filtering or add a runtime CSS grammar validator.
• Separate logical rule/node identity from successful CSSOM attachment. Each generated node may have zero or one attached top-level CSSOM node; a logical rule can have multiple generated nodes. Compute insertion/deletion offsets from actual attachments.
• Make insertion failures local to the rejected node. Preserve supported siblings and subsequent rules in Rust order. Distinguish browser parsing rejection from internal index/bookkeeping errors; do not label every exception as unsupported CSS.
• Delete only nodes actually owned by the removed rule. A rejected node must never consume an adjacent rule's deletion slot.
• Build the same attachment mapping for fresh rendering, snapshot adoption, refresh, hydration and fallback. Match the browser-parsed projection while retaining strict checks for changed, extra, missing, duplicated or reordered supported rules/resources. Removing the node-count assertion alone is insufficient.
• Preserve complete engine snapshots and resource accounting. Browser omission must not change semantic output or masquerade as successful physical insertion.
• Add permanent focused regressions and document the distinction between generated CSS and browser-attached CSS. This is a runtime correctness fix, not a class-language change.

Acceptance and validation

• Rejected nodes before, between and after supported nodes work within one multi-node rule and across separate rules.
• Insert/delete/reinsert, shared classes, refresh, retention cleanup and last-reference removal preserve unrelated styles and resources.
• Static, SSR, runtime and progressive paths retain the supported 21px declaration. Hydration and later DOM changes do not introduce style loss.
• Cover unknown selectors and browser-dropped contents inside wrappers, supported siblings, all utility layers, Document and ShadowRoot.
• Existing hydration tampering tests continue to reject actual mismatches.
• Run focused and then affected runtime e2e in Chromium, WebKit and Firefox; report unrun/environment-blocked cases honestly. Run runtime lint, type-check and build, and relevant server/hydration tests.
• Measure runtime insertion/deletion/hydration hot paths and complete runtime JS/Wasm/manifest payload against the same baseline/workload. Remeasure regressions above 5% and explain the cost; do not recover speed by weakening matching.

Boundaries and integration

No new syntax, Manifest/hydration wire shape, browser-support database, compiler fallback or release/CI changes are intended. The nonce/atomic-delivery follow-up #463 shares hydration code; land this mapping work first, then integrate #463 and run their combined matrix once. Add results to #451 and #454 rather than duplicating their broader audits. Preserve the ongoing #445 worktree changes.