[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

What happens

tests/test_next_app_route_dylib.sh fails at the first cold start when invoked from a working directory outside the repository:

perry: FATAL: unwind tables are missing from this runtime build (0 frame(s) visible to the unwinder).

Re-running the identical command from the repo root passes cleanly. Observed on 695daf302b (bench mini, macOS 26.5.1 arm64) during the #8040 acceptance run.

Why

The gate builds its provider runtime dylib with cargo build --manifest-path <worktree under $TMPDIR>/…. Cargo discovers .cargo/config.toml from the invoking working directory, not from the manifest path — and that file is the sole supplier of

[build]
rustflags = ["-C", "force-unwind-tables=yes"]

which #7302's exception transport requires: panic = "abort" omits unwind tables by default, so without the flag every throw crossing a runtime helper frame is stranded. Run from outside the repo, the provider runtime is built without unwind tables and the runtime's own self-check fires on the first try.

Why it is worth fixing rather than documenting

The failure names the wrong culprit. It reports a property of the runtime build ("unwind tables are missing") with no hint that the cause is the caller's cwd, and it appears at cold start 1 — i.e. after a ~25-minute compile — so the feedback loop is expensive. Anyone hitting it will reasonably suspect the runtime build, the profile, or #7302 itself before suspecting cd.

CI is unaffected (it runs from the repo root), which is exactly why this can sit latent.

Suggested fixes

• Have the script cd to the repo root itself, or pass --config / set CARGO_BUILD_RUSTFLAGS explicitly for the provider build so the flag cannot depend on cwd. The script already computes repo_root.
• Optionally assert early: if the built provider runtime lacks unwind tables, fail before serving with a message naming the cwd/rustflags cause rather than letting the runtime's self-check surface it 25 minutes later.

Same class as the other cwd-sensitivity in this fixture family fixed by #8209 (the host previously ran from .next/server, which broke Next's per-request routes-manifest.json open).