fix: lightningcss fails with html-proxy

[Marabyte]

Description

Fixes a bug when using Lightning CSS with Vite Server and html-proxy

Additional context

The issue was originally found when attempting to use Storybook with + Vitejs 4.4 with the lightningcss optioins enabled.

The shell app builds but when build the preview iframe it breaks with the error:

node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: GenericFailure] {
  code: 'GenericFailure',
  plugin: 'vite:css',
  id: '\x00/iframe.html?html-proxy&direct&index=0.css',
  pluginCode:[css code]
}

I would guess the problem is here: https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/css.ts#L2176:L2181

When processing CSS from proxy the filePath is an empty string or a relative path without a filename so we fail the first condition and try to read the file from the file system.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sapphi-red]

When running the playground, I got "" (empty string) as a value of filePath. I think this doesn't make sense and it's a bug in Lightning CSS. But I think it's fine to merge this as a workaround for now.

[patak-dev]

We can merge this PR as a temporal patch as suggested, but I think more tests are needed and the way id is converted to filename here doesn't seems correct to me. What happens when the id is a virtual module? Several html-proxy ids could end up mapped to the same filename, no? And then this filename is resolved and added to deps. Shouldn't there be a way to respect the id that has already been resolved and for which we already have the src and avoid re-resolving it?