Append inserted rules to the buckets instead of rebuilding

[arrufat]

Based on #3467 (independent of #3468 / #3469).

CSSStyleSheet.insertRule called sheetModified, so the next visibility query re-parsed every stylesheet in the document: every selector re-tokenized, every @media query re-evaluated, every layer re-ranked. CSS-in-JS libraries insert rules one at a time, and a component that reads layout right after mounting pays a full rebuild per rule.

StyleManager.ruleInserted now appends directly when the rule is a style rule appended at or after the sheet that emitted the last visibility rule (last_rule_sheet, tracked by the rebuild and by appends). That is the invariant the fast path needs, "no rule with a higher document order exists", rather than list position, so a trailing <style> holding only keyframes or @font-face does not force rebuilds on the sheet before it. The appended rule packs the next document order and, being unlayered, UNLAYERED_RANK; unlayered rules now carry that rank from creation on the rebuild path too, so an append is byte-for-byte what a rebuild would produce and stampRuleList only touches layered rules. An append that sets none of display / visibility / opacity / pointer-events (most CSS-in-JS rules) changes nothing and does not even stamp the memo. Everything else still rebuilds: an insert in the middle, an insert into an earlier sheet, an at-rule, or an insert while a rebuild is already pending.

Two things this cleaned up on the way:

• addRawRule (the <style> text path) folded declarations with a plain overwrite, so .x { display: none !important; display: block } read as block until cssRules was touched and the CSSOM path took over. It now shares the !important-aware fold the inline scan already used, and materializing a <style> sheet's cssRules no longer counts as a sheet change since both paths agree.
• One addVisibilityRule replaces the three copies of the per-selector loop; bucket uses getOrPutValue; Selector.rightmost() is shared with the selector matcher.

Tests: a unit test asserts the append path leaves dirty clear and agrees with the rebuild path on ordering, and that middle inserts and at-rules rebuild; fixture scripts check specificity ordering across appends, appends to an earlier sheet, an unlayered append outranking a layered rule, and the !important text case surviving cssRules materialization.

Numbers (ReleaseFast, static theverge fixture): a loop of 200 × insertRule each followed by checkVisibility() goes from 3.0 ms to 0.5 ms, median of 3.

[karlseguin]

It's a good chance, but it needs to be rebased, and, in particular, it conflicts with the --* custom property support. insertRule(":root { --brand: red }") would get ignored now.

[arrufat]

Merged main in. You were right: the fast path only looked at visibility properties, so a rule with only --* declarations was treated as "nothing changed" and never registered.

Both paths now go through the same addSelectorRules, which registers a rule's custom declarations and its visibility rules, and returns whether it added anything. An appended :root { --brand: red } reaches custom_rules like it does on a rebuild. If that property was already looked up, its lazily parsed selectors are cleared so the next lookup sees the new rule.

Added a case to custom_properties.html that reads --brand, appends the :root rule to the last sheet, checks the value changed, then deletes it and checks it went back.