test: Next App Route dylib provider host hangs during cold start (route itself serves 21 requests)

[proggeramlug]

Symptom

tests/test_next_app_route_dylib.sh hangs indefinitely. The provider host builds
and links fine, prints its ABI hash, and then never serves a request — the
harness waits until it is killed. CI shows this as the
Production App Route provider gate step failing (e.g. run 31993068277 on
main).

Reproduced locally three times today, on three different trees:

tree	stack at hang
main + #8313	main → js_wait_for_event
main + #8377	main → run_microtasks → js_timer_tick → aux_has_active → js_node_http_server_has_active

Both are the same shape: 0.0% CPU, no child process, parked in the event-loop
pump, last output Provider ABI hash: …. The second stack is the more
informative one — the host is asking whether the HTTP server has active handles
and getting an answer that keeps it idle, so it never begins serving.

What it is NOT

• Not [test] test_next_app_route_dylib.sh is silently cwd-sensitive: run from outside the repo, the provider runtime loses -C force-unwind-tables and fails 25 minutes later naming the wrong cause #8258 (cwd-dependence). That was a real, separate defect — Cargo reads
  .cargo/config.toml from the invocation directory, not --manifest-path, so
  the provider runtime lost -C force-unwind-tables=yes. fix(test): make Next dylib provider build cwd-independent #8377 fixed it, and the
  hang persists unchanged afterwards.
• Not a stray-node_modules resolution problem. A worktree placed under
  /private/tmp does fail differently and fatally
  (JavaScript runtime (V8) support has been removed on
  /private/tmp/node_modules/@opentelemetry/api, because Node resolution walks
  up out of the fixture), but from a normal worktree root that import is only
  Warning: Could not resolve and the build proceeds to the hang above.

Why it matters

This is the acceptance gate for the #8034/#8040 production Next App Route, and it
is the natural end-to-end check for object-layout and ABI changes — exactly the
class that has silently broken split modules before (#8204 → #8228/#8241). While
it hangs, layout-changing PRs lose their most realistic verification: #8313 (the
40-byte header) had to fall back to the gap suite for that reason.

Suggested starting point

js_node_http_server_has_active / stdlib_pump::aux_has_active — establish
whether the server handle is registered at all in the dylib-provider
configuration, or whether it is registered but reports inactive so the pump never
dispatches it.

[proggeramlug]

Correcting my own report above. I wrote "never serves a request". That is
wrong, and it matters because it points at the wrong place.

The harness's earlier phases all pass, identically in both reproductions:

PASS: pinned Next 16.3.0 / React 19.2.4 lockfile
PASS: production bundle exports routeModule.handle for /api/benchmark
PASS: 21 production App Route requests
PASS: pinned production Next App Route Node oracle

So the route logic, the production bundle, and 21 real App Route requests are
fine. The hang is specifically in the dylib provider-host cold start, which
is the phase right after Provider ABI hash: …:

run	last line reached
main + #8313	Provider ABI hash: f41325… then hang
main + #8377	Provider ABI hash: 9e85ab… then hang

Both stall there with the host at 0.0% CPU, no child process, parked in the
event-loop pump — the second sample showing
run_microtasks → js_timer_tick → aux_has_active → js_node_http_server_has_active.

One more caveat on the evidence: the provider host exited during cold start 1
line in the #8377 run is my kill, not an independent failure verdict, and
FIXTURE_EXIT=1 reflects that kill. The 35 minutes of 0% CPU beforehand is the
observed fact; the exit code is mine.

Revised starting point: not "the server never comes up" in general, but "the
dylib provider host's HTTP server never registers as active during cold start,
while the same route serves fine through the non-provider path in the phase
immediately before".