SSR stream never closes when a rejected fragment abandons a pending serialized sibling #3165

Describe the bug

On current next (07471da2, 2.0.0-rc.4), a streamed <Loading> fragment can reach its terminal error state while an async sibling inside the same fragment remains pending. The error swap, serialized error, $df marker, and static tail are all delivered, but the response never calls end().

The abandoned sibling still has a deferred registered with the hydration serializer. Fragment rejection removes the fragment from the renderer registry, but it does not terminally settle serialized deferreds belonging to the discarded subtree. serializer.flush() therefore waits forever and onDone never closes the response.

This holds the HTTP response and render resources open until the client or proxy disconnects.

Minimal reproduction

import { Errored, Loading, renderToStream } from "@solidjs/web";
import { createMemo } from "solid-js";

const delay = (ms: number) => new Promise(resolve => setTimeout(resolve, ms));
const never = new Promise<string>(() => {});

function Child() {
  const bad = createMemo(async () => {
    await delay(10);
    throw new Error("late-boom");
  });
  const stuck = createMemo(async () => never);

  return (
    <div>
      {bad()}
      {stuck()}
    </div>
  );
}

const completed = renderToStream(() => (
  <html>
    <body>
      <Errored fallback={<p>caught</p>}>
        <Loading fallback={<i>loading</i>}>
          <Child />
        </Loading>
      </Errored>
      <span>tail</span>
    </body>
  </html>
));

const ended = await Promise.race([
  completed.then(() => true),
  delay(2000).then(() => false)
]);

console.log(ended); // false; expected true

<Errored> is not required. The minimized <Loading>-only shape with one rejecting hole and one never-settling hole also hangs.

Expected behavior

Once the fragment rejects terminally and its subtree is discarded, async serialization owned only by that abandoned subtree must no longer gate response completion. The error fragment should stream and the response should close.

Actual behavior

All terminal content is emitted, but the document request remains pending forever.

Controls

• Rejection without the stuck sibling closes normally.
• A slow sibling that eventually settles closes normally after settlement.
• A never-settling memo in a separate, still-live <Loading> boundary correctly keeps the stream open.
• The same failure reproduces with a nested pending boundary inside the rejected region.

These controls distinguish abandoned serialization from independent live work that should continue gating the response.

Implementation notes

• Server async memos create and serialize a deferred in packages/solid/src/server/signals.ts (recordSlot / ctx.serialize).
• Fragment rejection removes the fragment registry entry in packages/web/src/server.ts, after which flushEnd() reaches serializer.flush().
• Serializer completion intentionally waits for every serialized async value.
• Disposal prevents retry work but does not reject or resolve the already-serialized sibling deferred.

This is related to the always-settle work discussed in #3003, but it is a different rejected-fragment lifecycle gap: #3003 fixed retry convergence and superseded-node deferreds, while this reproduction terminally rejects a fragment that still owns a separate pending serialized sibling.