walkJourney in src/release/journey.ts walks a stranger's journey against any live forge URL and cleans up after itself #11813

walkJourney is in src/release/journey.ts and passes its five tests, bun scripts/gate.ts and bun x tsc --noEmit locally. Nothing calls it until part 3 of #11158, so scripts/unreached-allow.json lists the module for now.

What it does

• The walk: walkJourney({ base, fetch, ask, now }) follows the stranger's journey in order: it opens /, names a probe-xxxxxxxx forge, waits for it to be ready, signs up with a username and password, posts one tiny ask and polls for crew activity. It returns { ok, screens, readyMs, firstActivityMs, failure?, forge, removed }.
• Failures: a failed step comes back as words in failure, for example "the forge was not ready in 20 s" or "the account could not be made: it answered 503".
• Budgets and safety: budgets come from FIRST_FIVE_MINUTES, every request has a 10 s timeout, and there is no shell, only fetch.
• Cleanup: afterwards, pass or fail, it cancels the crew run and removes the forge with POST /forges/<name>/remove.
• Extra options: adminToken, pollMs and sleep, beyond the four in the issue. removed reports whether the removal worked.

Choices to look at

• Removal needs an admin token. The host only lets an admin remove a forge. Without adminToken the forge stays, and the result says removed: false.
• Activity is read from two places. The home's crew card only lists apps owned by the forge's spawned organisation. The first ask creates an app owned by the asker, so the card never shows it. The walk therefore also treats a run linked on the app's /runs page as activity. That deviates from "polls the forge's home" in the issue; say if you'd rather change what the home shows instead.
• I did not write a second walker. I followed the same requests as test/stranger-three-screens.test.ts, but did not import its code.

Tests (test/release-journey.test.ts)

• Setup: the tests serve a real parent and child forge with a stand-in crew.
• Passing walk: one walk passes with its timings and the removal asserted.
• Failing walks: one walk has POST /claim answering 503 and names that step; another never becomes ready. The removal is asserted in both.
• Edge cases: a run without an admin token, and a non-http address refused before any request.

To try

• bun test test/release-journey.test.ts
• Against a live forge, call walkJourney({ base: "https://…", adminToken }).

Closes #11786

I merged main into the branch and pushed it. The only conflict was scripts/unreached-allow.json, and the merge commit is 374d271b1.

main had removed src/tui/ui/qr.ts from the allow list, and this branch had added src/release/journey.ts. The resolved list keeps journey.ts and drops qr.ts. It is now page_budget.ts, page_budget_read.ts, release/journey.ts and spawn/pod.ts.

I ran bun scripts/gate.ts, bun x tsc --noEmit and test/release-journey.test.ts (5 pass, 0 fail). Gate and tsc printed nothing. I did not run the full suite; the forge's check does that on this push.

This fixes the one failing check on #11813, the cookie-site census in test/cookie-flags.test.ts. I ran that test file and bun x tsc --noEmit locally and both pass. The forge's full check has not run on the new push yet.

The census counts every Set-Cookie or sessionCookie( mention in src/, and it flagged src/release/journey.ts. That file only reads the sign-in response's set-cookie header so the walk can carry the session. It sets no cookie. I added it to the census's list of unreached files with that reason instead of changing the code, so the test was what needed updating, not the walker.

I did not run the journey tests this turn, since only the census list changed.