avoid double import of $env/dynamic/[mode] modules

[Rich-Harris]

Attempt to fix #5941. No test because the bug doesn't happen inside the workspace

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: af28ffc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benmccann]

Will this prevent the user from being able to change the env files after server startup?

[Rich-Harris]

Changing .env will cause the dev server to be restarted

[benmccann]

lgtm. although I haven't fully followed what's happening and why this fixes things. @bluwy and @dominikg might be understanding the situation more closely

[bluwy]

@benmccann it looks like the issue is that we're slightly tapping into Vite's internals to load env-private.js and env-public.js, where if Vite controls the entire import analysis flow, it would usually load them as /node_modules/@sveltejs/kit/src/runtime/env-private.js. Only imports outside of root would (usually?) use /@fs, which this PR changes to emulate this.

Ideally we would put these runtime files in pkg.exports, so we can ssrLoadModule them directly without resolving the path ourselves, but @Rich-Harris brought up that we want to keep this private API and intellisense-wise.

I think the solution now is fine, but if more issues appear later, it could be worth investigating a safer way.