fix(parser): don't drop @container/@layer at-rules on CSS parse (#5969)

[TowyTowy]

Problem

Closes #5969. @container (and other nestable at-rules like @layer) are silently dropped by the CSS parser on engines that expose a real numeric CSSRule.type.

parseNode in BrowserParserCss only entered the nestable-at-rule branch when the legacy type was falsy: (!type && getNestableAtRule(node)). Chrome reports type === 0 for these newer rules so it happened to work there, but any engine that returns a numeric type (jsdom returns 17 for CSSContainerRule) fell through every branch and the entire rule — selectors, styles and condition — was discarded. When the rule survived at all, this is what produced the reported invalid export @container portable(max-width: 639px) with the missing space.

Solution

Detect nestable at-rules with getNestableAtRule(node) regardless of the numeric type. getNestableAtRule only matches when the rule's cssText starts with the exact @<name>, so normal style/keyframe rules are untouched. The parsed condition keeps the container name and query separated by a space, so the exported CSS is valid again: @container somename (min-width: 300px){...}.

Tests

• Un-skipped and corrected the pre-existing Parse rule with @container at-rule spec (its output no longer includes selectorsAdd: '', matching the @media specs). It fails before this change (the rule is dropped) and passes after.
• Added an anonymous @container parse spec and a toCSS spec asserting the space is preserved on export.
• Full parser / css_composer / code_manager / dom_components / selector_manager / style_manager suites pass with no regressions (792 passing).

Disclosure

Prepared with assistance from Claude (AI); the change and tests were reviewed and verified locally by the author (pnpm test, eslint, prettier --check all clean).