feat: additional $app/manifest goodies, better route typings

[elliott-with-the-longest-name-on-github]

Based on #16580. Adds a few goodies:

• PageRouteId and EndpointRouteId, which combine to make up RouteId — these make the internal types a bit cleaner and allow you to discriminate between which routes do what if needed
• page and endpoint booleans on each entry in $app/manifest.routes, allowing routes to be filtered by capability; routes containing both +page and +server have both set to true
• A ManifestRoute discriminated union that narrows id to the corresponding page-only, endpoint-only, or combined route IDs
• A private LayoutParamsId alias for the IDs accepted by LayoutParams, which now correspond specifically to directories containing layouts
• More accurate layout load types: a colocated endpoint-only route is no longer included in a layout’s possible event.route.id values, since endpoint requests do not execute layouts

Layouts only run for page routes, not endpoints. Previously, a directory with both +layout and +server incorrectly included its endpoint-only ID in the layout’s possible event.route.id type, even though that value can never occur at runtime. The change restricts it to page IDs that can actually execute the layout.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from ed237b6:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/ed237b6803ecf7aa7b6cc8f4c7d0e7e9497679b6

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16594

[changeset-bot]

🦋 Changeset detected

Latest commit: ed237b6

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	Minor

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

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-16594-svelte.vercel.app/

[Rich-Harris]

Bikeshedding time! Is it EndpointRouteId, and endpoint: true, or ServerRouteId and server: true? We do use the 'endpoint' terminology in various places in the docs, but the latter has better symmetry with +page and +server.

[elliott-with-the-longest-name-on-github]

Good question... I went with endpoint to disambiguate between that and server load, but I don't really know that it's that confusing, so I don't have strong feelings either way.

[dummdidumm]

I think endpoint is more descriptive (we even use that terminology in our framework code). server feels too ambiguous, could also mean "server load function". Do we say "server routes" anywhere?

[Rich-Harris]

We do — e.g. in https://svelte.dev/docs/kit/web-standards#Fetch-APIs-Request we say

An instance of Request is accessible in hooks and server routes as event.request.

'endpoint', to me, includes things like /<route>/__data.json and /<route>/__route.js and /_app/remote/<id> and so on. 'Server route' implies things that were explicitly authored as such, with a +server file

[dummdidumm]

That example you mention can also mean +server.js and server load functions. I still think endpoint is better. The underscore stuff is an implementation detail normal users know nothing about