Commit f3694d1

"@solidjs/signals": patch

An `<Errored>` heals once no reader it caught still reads the failed source, instead of staying on its fallback after navigating to another branch (#4644). This covers an error read only by memos (a `<Show>`/`<Match>` condition), and a source something outside the boundary still reads: a hoisted memo, a derived store or projection, a reader under another `<Errored>`.

"@solidjs/signals": patch

An error boundary output read only behind fallbacks now holds nothing when it reaches them through a memo or another error boundary built outside the `<Loading>`, or is not read at all; `LOADING_ON_OUTSIDE_HOLD` no longer fires while the re-armed fallback is on screen.

"solid-js": patch

"@solidjs/signals": patch

A non-keyed `<Show>`'s or `<Match>`'s narrowed accessor read inside an `isPending()` thunk no longer throws the stale-value error for a branch that mounted in the flush its condition landed in, so the thunk's later reads link and the verdict flips (#4648). The exemption holds only inside a verdict window (`isPending` / `latest`): a plain read of the accessor while its branch's opening is held still throws, rather than hand out the committed falsy.

"@solidjs/web": patch

Fail `renderToStream` when an asynchronous value cannot be serialized after its key was handed to the default serializer, if that happens before the first flush (an awaited render, or before the shell went out). The render tears down without calling `onCompleteAll` and nothing is sent (#4647). Synchronous serialization failures and custom serializers keep their existing behavior.

"@solidjs/web": patch

Aborting `renderToStream`'s `signal` now settles and ends every streaming consumer. Before, the promise from `pipeTo` could stay pending forever after an abort, the `readable` view and a `createSSRResponse` body never closed, and a `pipe` sink was never ended, which kept the request alive. Now nothing more is written and each surface ends cleanly, as a close and not an error, since the bytes already sent stay sent: `pipe` ends its sink, `pipeTo` closes its writable and resolves without rejecting, and `readable` closes. `createSSRResponse` ends its `200` body after the shell and still resolves with a bodyless `500` before it. `onError` and `onCompleteAll` are not called. The awaited form rejects with `signal.reason` (see the companion changeset) (#4646).

"@solidjs/web": patch

Reject `renderToStream` thenable consumers with `signal.reason` when its `signal` aborts, including consumers registered after cancellation. Render failures still resolve with the available HTML.

"@solidjs/web": patch

`renderToStream`: an async value that resolves to something the serializer cannot handle after the first flush (midstream) now rejects its key on the client instead of leaving it pending forever (#4647) — and with it every promise or async iterable inside the value that already went out (a nested promise, an async iterable's later items), and every other key on the same value. The failure is still reported as `{ kind: "render", handling: "serialize" }` and the render completes; the payload settles the key's promise with an error that says it is a serialization failure and names the key (the failure's own text stays on the server). The hydrating read throws into the nearest `<Errored>`, whose fallback replaces the server-rendered content until `reset()` or an input change reruns the computation as a client fetch. With no `<Errored>` above, it is uncaught like any rejected key. Before the first flush the render fails instead (see the other changeset).

document face: reason `signal`, sink ended once and never written after the abort;

#4646).

- `await renderToStream(...)` **never rejects for a render error**

(only an aborted `signal` rejects it, with `signal.reason`, #4646); render errors go to