SvelteKit security model doesn't cover +page.svelte content

Describe the problem

SvelteKit allows you to visually deny access to a route using server hooks, but the compiled +page.svelte's filename is always public as .svelte-kit/output/client/_app/immutable/entry has import references to all routes' bundles.

This can leak internal API calls and DOM content on the supposedly-private route which is harmful for my blog use-case where I'd like to have truly private posts[^1]. It is also misleading for the developer who may not telepathically intuit the SvelteKit hydration model.

[^1]: Which I want to be able to just write in Svelte so I can have little experiments inline and so on using all the tailwind tooling goodness I have on the rest of the site.

Describe the proposed solution

• +page[.server].ts should gain an additional export const private = true; export which restricts the appropriate file in _app/immutable/nodes/[^2] on the server.
• the security model should be documented such that you can understand exactly what is exposed to the end-user & on what conditions.

[^2]: What about _app/immutable/nodes/? Do we wanna go that far and also try to prune dependencies that are only used on private pages?

Alternatives considered

• ❌ I could put all the secret content in +page.server.ts which would be incredibly painful to edit and not give me access to tailwind (because of class pruning) nor <svelte:self> or any of the other ✨magic✨. This doesn't solve obscuring API calls.
• 🟠 I could put all the secret content in a component and then import() the component in my secret/+page.svelte or even eval("import")() if vite is too clever.

Importance

nice to have (workaround probably possible, otherwise it'd be critical)

Related issues

https://github.com/sveltejs/kit/issues/10072

The issue points to server hooks, +page.svelte and +page.server.ts, .svelte-kit/output/client/_app/immutable/entry, _app/immutable/nodes/, and packages/adapter-node/src/handler.js. Start by tracing how private routes are exposed to the client, then define and document the security model, including what the proposed private export protects and whether private-page dependencies are pruned.