feat(router): support ctx.rendered() on streaming (loading()) trees - #553

…548)

Completes the render-barrier feature: a DSL loader can now `await ctx.rendered()`
and read handle data on a route tree that uses `loading()`, instead of the call
throwing. Closes #548.

The key realization is that the signal already exists. A loading() handler runs
EAGERLY — only its rendered output streams behind Suspense — and its full async
execution (including its push() calls) is tracked in the handle store
(fresh.ts: trackHandler(handler(context)) -> store.track). So handleStore.settled
(sealed AND no in-flight tracked promises) already waits for streaming handlers.
The only bug was that the barrier resolved synchronously right after
resolveAllSegments(), building an incomplete handle snapshot while those handlers
were still in flight.

Change (loader-resolution.ts), minimal blast radius:
- Remove the `_treeHasStreaming` reject guard.
- rendered(): for streaming trees, after the barrier resolves, seal the handle
  store and `await handleStore.settled` before resolving. The seal is safe — every
  handler is tracked during resolveAllSegments, so none is unregistered by barrier
  time; pushes happen within those tracked promises (before settled); the payload's
  later stream() auto-seal is idempotent.
- ctx.use(handle): for streaming trees build a fresh snapshot from the now-complete
  store (the eager barrier snapshot is incomplete for streaming).
- Keep the handler-awaits-loader deadlock guard (the real cycle guard) and the
  handler-invoked-loader guard.
- Non-streaming path is byte-for-byte unchanged.

Tests:
- Unit (rendered-barrier.test.ts): streaming tree now waits for a loading()
  handler's deferred push and reads complete data; deadlock guard still rejects.
- E2e (rendered-barrier.test.ts, dev + production): repurposed the old
  "streaming-rejected" route into "/streaming" — a loading() handler that pushes
  its handle data AFTER an await (during streaming, past the barrier); the loader
  reads it and resolves prices. Verified the semantic matrix stays green in both
  modes.

Docs: rendered-barrier.md status/scope/guard-table updated; "Why Not Streaming"
reframed to "How Streaming Works". loader-types.ts rendered() doc drops the
non-streaming restriction. router.named-routes.gen.ts updated for the route rename.

… settle wait

Review P1: on a streaming tree, rendered() keeps waiting on handleStore.settled
AFTER the render barrier resolves — but _resolveRenderBarrier tore down the guard
state (_renderBarrierWaiters / _handlerLoaderDeps) and the handler-side dependency
tracking went dark once _renderBarrierSegmentOrder was set, both at barrier time.
So a loading() handler could resume during that wait, `await ctx.use(theSameLoader)`
undetected, and deadlock (the handler waits for the loader; the loader waits for
settled, which waits for the handler). That violated the "handler awaits the same
loader throws" contract.

Fix:
- request-context.ts _resolveRenderBarrier: for streaming trees, do NOT clear the
  guard state at barrier time. Keep it live and tear it down on handleStore.settled
  (by then every tracked handler has finished — none can await a loader anymore).
  Non-streaming is unchanged (clears immediately). Added _renderBarrierGuardClosed.
- loader-resolution.ts: gate the Direction-2 dependency tracking on
  _renderBarrierGuardClosed instead of _renderBarrierSegmentOrder, so it stays live
  across the streaming settle wait. Direction-1 now sees the kept waiters.

Tests:
- Unit (rendered-barrier.test.ts): the mock _resolveRenderBarrier now MIRRORS the
  real cleanup (immediate for non-streaming, settled-deferred for streaming). New
  regression: a handler that awaits a still-waiting rendered() loader DURING the
  streaming settle window throws (goes silent without the fix). 19/19.
- E2e (rendered-barrier.test.ts, dev + production): new /streaming-deadlock route —
  a loading() handler awaits a rendered() loader; the guard must error, not hang
  (a regression would time the test out). DeadlockLoader is `export const` so the
  expose-internal-ids transform injects its $$id (the guard keys on loader.$$id).
- Semantic matrix green; router.named-routes.gen.ts updated for the new route.

…ing deadlock guard

Review P2: the handler-to-loader deadlock guard used a plain `insideHandlePush`
boolean that is only true during a push callback's SYNCHRONOUS call. After an
async push callback's first await it resumes with the flag false. Before the P1
fix that was harmless (the guard window closed at the barrier), but P1 keeps
_renderBarrierWaiters live until handleStore.settled on streaming trees — so a
callback like push(async () => { await x; return ctx.use(RenderedLoader); }) that
resumes during the settle window would throw a false "Deadlock". A pushed promise
value is not tracked by settled and cannot block segment resolution, so it is not
a real cycle.

Fix:
- server/context.ts: add a push-callback ALS scope (runInsidePushCallbackScope /
  isInsidePushCallbackScope), mirroring the loader-scope ALS. Unlike a boolean, it
  survives the callback's awaits.
- loader-resolution.ts: run the push callback inside runInsidePushCallbackScope and
  gate the deadlock guard on isInsidePushCallbackScope() instead of the removed
  boolean — so an async callback's continuation stays exempt.

Tests:
- Unit (rendered-barrier.test.ts): streaming counterpart of the existing
  "push callback resumes after barrier" test — an async push callback that calls
  ctx.use(loader) DURING the streaming settle window must NOT throw. The mock pulls
  the REAL push-callback ALS via importActual so scope-survives-await is exercised
  faithfully (it throws without the fix). 20/20.
- Updated loader-cycle-detection.test.ts's context mock with the two new exports.
- Full unit (3386), e2e rendered-barrier dev + production (8/8 each), semantic
  matrix green.

Cleanup pass over the streaming rendered() changes (no behavior change):

- Cache the streaming handle snapshot once. rendered() now builds the complete
  snapshot after handleStore.settled and stores it in _renderBarrierHandleSnapshot,
  so ctx.use(handle) reads the cached snapshot uniformly instead of rebuilding it
  on every call for streaming trees. This also collapses the _treeHasStreaming
  ternary in ctx.use(handle) to a single `cached ?? buildHandleSnapshot(...)`
  expression — the snapshot's presence is now the only signal, with streaming vs
  non-streaming living solely at the point that decides when to populate it.
- Extract a closeGuard() closure in _resolveRenderBarrier so the three-line guard
  teardown is written once; the only streaming/non-streaming difference left is
  WHEN it runs (now vs. settled.then(closeGuard)).
- Fix stale comments that referenced the removed `insideHandlePush` boolean
  (now the isInsidePushCallbackScope() ALS scope), in loader-resolution.ts and the
  push-callback unit test.

Verified: typecheck, full unit (3386), rendered-barrier e2e dev + production (8/8
each), lint, format.