`transformPageChunk` semantics are broken with error page rendering

Describe the bug

The current transformPageChunk API is fragile as any errors thrown by the transformPageChunk handler cause an error page to be rendered using the same transformer but with dirty state.

Looking at the following example, the docs encourage storing intermediate state in the top-level event handler which is a no-go. There's no way for a consumer of this API to distinguish the new render from the previous. https://github.com/sveltejs/kit/blob/1164ffa83d7b4812c812e4e2d6f63e7b1ea1ef98/documentation/docs/40-best-practices/20-seo.md?plain=1#L92-L109

Reproduction

https://github.com/ckiee/svelte-reprod-transformPageChunk-done/

Logs

# (event invoke)     (done)      (call count)

0.4027095306061035 { done: true, i: 0 }
Error: something failed
    at Object.transformPageChunk (/home/ckie/git/svelte-reprod-transformPageChunk-done/src/hooks.server.ts:9:19)
    …
0.4027095306061035 { done: true, i: 1 } # we get another invoke with done and a start of a new html body
Error: something failed
    at Object.transformPageChunk (/home/ckie/git/svelte-reprod-transformPageChunk-done/src/hooks.server.ts:9:19)
    …

System Info

System:
    OS: Linux 6.14 cpe:/o:nixos:nixos:25.11 25.11 (Xantusia)
    CPU: (24) x64 AMD Ryzen 9 7900X 12-Core Processor
    Memory: 8.34 GB / 30.51 GB
    Container: Yes
    Shell: 5.2.37 - /run/current-system/sw/bin/bash
  Binaries:
    Node: 24.4.1 - ~/.nix-profile/bin/node
    Yarn: 1.22.22 - ~/.nix-profile/bin/yarn
    npm: 11.4.2 - ~/.nix-profile/bin/npm
    pnpm: 10.13.1 - ~/.nix-profile/bin/pnpm
    bun: 1.2.18 - ~/.nix-profile/bin/bun
  Browsers:
    Chromium: 138.0.7204.157
  npmPackages:
    @sveltejs/adapter-auto: ^6.0.0 => 6.0.1
    @sveltejs/kit: ^2.26.1 => 2.26.1
    @sveltejs/vite-plugin-svelte: ^6.0.0 => 6.1.0
    svelte: ^5.0.0 => 5.37.0
    vite: ^7.0.4 => 7.0.6

Severity

serious, but I can work around it

Additional Information

The real world workaround&usage: https://gist.github.com/ckiee/41e8d84cef29df2055ddf20206934125

Start with the transformPageChunk handler in the linked reproduction and compare the initial render with the error-page render described in the issue. Trace how the server invokes the handler after an error; done means the new error-page render does not reuse dirty state from the failed render and the reported reproduction no longer shows the duplicate failing invocation.