fix(module-runner): allow already resolved id as entry

[hi-ogawa]

Description

• Closes ssrLoadModule("/@id/__x00__virtual:xxx") fails on Vite 6 #19764
• Closes [vite] cannot find entry point module ... error when a runner full reloads with a virtual module entry #19283

I thought ensuring entry module resolveId makes sense, but that's causing inconsistency with how already resolved virtual module id is handled in other places. I think we can remove this to match transformRequest behavior in general. Otherwise, I'm not sure how to fix #19283.

I didn't add a test case for #19283, but confirmed the repro is fixed https://stackblitz.com/edit/github-i1t4t7n4?file=repro.js (EDIT: added in "virtual module hmr")

[hi-ogawa]

/ecosystem-ci run

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vite@19768

commit: 22c17f2

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 385baa8: Open

suite	result	latest scheduled
vike	✅ success	❌ failure
unocss	✅ success	❌ failure
storybook	✅ success	❌ failure
nuxt	✅ success	❌ failure
vite-plugin-vue	✅ success	❌ failure
laravel	❌ failure	✅ success
sveltekit	❌ failure	✅ success
vite-environment-examples	✅ success	❌ failure
vite-plugin-svelte	❌ failure	❌ failure
vitest	❌ failure	✅ success
vitepress	✅ success	❌ failure
vuepress	✅ success	❌ failure
quasar	✅ success	❌ failure

✅ analogjs, astro, marko, vite-plugin-react-swc, vite-plugin-pwa, react-router, previewjs, vite-plugin-cloudflare, qwik, histoire, vite-plugin-react, rakkas, ladle, waku, vite-setup-catalogue

[sapphi-red]

I think #19283 should be fixed. On the other hand, I'm not sure about #19764. I prefer to be not fixed and keep the behavior as-is. But that'd require a complex refactor (probably, the normalization for browsers, which is also done for the module runner, needs to be removed) and I think it's not the right time to do that. To sum up, I think we can go with this PR. But I think we should have a test for #19283 as that's the reason why we are changing the behavior here.