No AST produced when media query has an invalid `calc` even with `error_recovery = true`

I'm working on migrating some infra to use LightningCSS.
Specifically I'm using LightningCSS as a parser to allow me to extract class names from CSS files.

Our codebase (unfortunately) makes use of postcss css modules @values -- which are unsupported by LightningCSS and that's okay -- the unknown rule provides me with tokens that I can walk through to do my analysis and it works well.

In the very few cases that LCSS would emit a syntax error, error_recovery = True makes LCSS emit an AST that's more than usable enough to extract the information that I need.

The trouble I've run into is specifically the following code:

@media (min-width: calc(baseUnit * 1)) {
  .className {
    color: red;
  }
}

This code emits no media query AST node at all and so there's no way to visit and grab .className.

For comparison if I remove the calc then the AST is produced just fine!

/* produces an AST */
@media (min-width: baseUnit) {
  .className1 {
    color: red;
  }
}

/* produces an AST */
@media baseUnit {
  .className2 {
    color: red;
  }
}

Or if the calc is on a CSS property then it also produces an AST just fine:

@media (min-width: baseUnit) {
  .className {
    left: calc(baseUnit * 1);
  }
}

It's specifically the case where the the calc is nested within the media query's condition that the AST completely barfs.

Look: I know that this is a bit of an abuse of LightningCSS to do this -- but sadly the only other option that I know of is to go back to using postcss's parser which is 100x slower. I would love it if it could produce an AST in this case.

Reproduce the issue with the provided @media and calc examples while error_recovery is enabled, then inspect the generated AST for the media query and nested class. The fix is complete when the invalid calc still produces a usable media query AST containing the class, matching the behavior of the comparison cases.