fix: preserve trailing slash when error boundary truncates branch

[FrankFMY]

Summary

• When trailingSlash = 'always' is set at the page level and the page's load function throws an error, the client-side error handling truncates the branch to the nearest error boundary — losing the page node's trailingSlash config and causing the URL to change (e.g. /test/ → /test)
• Default to 'ignore' instead of 'never' when an error is present in get_navigation_result_from_branch, so the URL pathname stays unchanged
• If a layout above the error boundary has its own trailingSlash config, it still overrides the default via the branch iteration

Fixes #13516

Test plan

• Added test route routing/trailing-slash/error/always-error/ with trailingSlash = 'always' and a load function that throws error(500)
• Added integration test verifying URL pathname is preserved after CSR navigation to the error page
• All existing trailing slash tests pass (12 passed, 4 skipped no-js)
• Unit tests pass (424 passed)

[changeset-bot]

🦋 Changeset detected

Latest commit: 4d16a90

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

[svelte-docs-bot]

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

[benmccann]

The CI failures will need to be fixed

I'm curious, how are you picking things to work on? We're trying to get ready to start working on SvelteKit 3, and have some big plans for it. We don't necessarily want to get bogged down reviewing smaller issues if they're not things people are frequently running into or are causing significant difficulty for users

I'm also curious, is there a particular model you're using? I've still been testing a few different ones out myself

[FrankFMY]

Thanks for the feedback! I'm using Claude Code CLI with Claude 4.6 Opus — working on open-source contributions in my spare time so my limits don't go to waste, and I get to help projects I genuinely care about.

For picking issues — I tend to look for bugs that are clear correctness issues with a small fix surface, so the review burden stays minimal. This one seemed like a good fit: it's a real bug affecting anyone using trailingSlash with error boundaries, the fix is a single line, and it's been open for a while. But I totally understand the priority shift towards SvelteKit 3 — happy to focus on issues that are more impactful or aligned with that direction if you have suggestions.

Also, I just genuinely enjoy contributing back to projects I use daily — I have plenty of energy outside of work and got tired of writing code just for myself. Figured I'd put that energy into something the community actually benefits from. Using AI tooling also helps me write clearer commit messages and descriptions, which hopefully makes reviewing easier on your end.