Fixes #98261

What

Turbopack build failed with Parsing CSS source code failed / Unexpected end of input on valid name-only @container queries:

@supports (container-type: inline-size scroll-state) {
  @container scroll-content {
    .foo { max-width: 100cqw; }
  }
}

This CSS is valid per CSS Containment Module Level 3 (named containers + scroll-state) and is emitted by nhsuk-frontend@10.6.1.

Why

lightningcss (1.33 / 1.0.0-alpha.72) correctly supports name-only containers via Option<ContainerCondition>. With error_recovery:true, it still emits an EndOfInput warning when parsing @container <name> { (no condition) and recovers with None.

turbopack-css/src/process.rs mapped ParserError::EndOfInput to IssueSeverity::Error, so the warning surfaced as a build error:

./src/app/repro.css:2:29 Unexpected end of input

How

Demote EndOfInput to Warning in the severity match (same as other recoverable parser warnings like UnsupportedPseudo*). The stylesheet already parses and minify/to_css succeed; only the severity caused the failure.

Repro: cptiv2020/turbopack-parsing-issue-repro — next@canary before fix fails at 2:29, after fix no longer fails. cargo check -p turbopack-css passes. Direct lightningcss test with error_recovery:true shows 1 warning EndOfInput at 1:29 now treated as Warning.

Test

• cargo check -p turbopack-css — pass
• npm run build on repro with next@canary before: Turbopack error 2:29; after fix: expected to pass (warning only)
• lightningcss direct parse with error_recovery:true → EndOfInput warning now Warning