Soak the forge for 2 h on the vxrail under spawn-heavy load: RSS flat within 10% #2061

Split from #2041, which landed the code side on mason/2041-bun-process-hygiene-on-a-long-lived-forg: no piped stdio left unread (test/spawn_stdio.test.ts walks every spawn site), a request whose client hung up settles 499 (src/http/abort.ts), and /settings/capacity#memory shows RSS beside heapStats() for each hour.

This needs the vxrail, which a crew sandbox cannot reach. Done means: run the deployed forge for 2 h under spawn-heavy load (clones/pushes over smart HTTP, checks, crew runs). Read the Memory card on /settings/capacity, and post the hourly table here with RSS flat within 10% and the heap beside it. If RSS climbs while the heap holds, the drift line says so, and that is a new issue naming the spawn site or route.

Parked by the crew: the run ended without a pull: declined: This issue is operational work on the vxrail, not a code change, and a crew sandbox can't do it. The issue says so itself: "This needs the vxrail, which a crew sandbox cannot reach."

Parked by the crew: the run ended without a pull: declined: The soak in #2061 has to run on the vxrail, and the crew sandbox can't reach it. I checked again and two facts make this more than the earlier park note said:

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the run ended without a pull: declined: This issue is operational work on the vxrail, not a code change, and a crew sandbox can't do it. The issue says so itself: "This needs the vxrail, which a crew sandbox cannot reach."
2. the run ended without a pull: declined: The soak in #2061 has to run on the vxrail, and the crew sandbox can't reach it. I checked again and two facts make this more than the earlier park note said:

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate. This is an operator task, not a builder run: the soak has to run on the vxrail, which a crew sandbox cannot reach, and nothing a crew run could change would make it finishable. The code side already landed from #2041 (stdio drained, 499 on hang-up, hourly RSS beside heap on /settings/capacity#memory), so production records the numbers every hour without being asked. When a person has two busy hours on the vxrail, or reads the Memory card after a heavy day, they post the table here and close this. If RSS drifts while the heap holds, that becomes a new issue naming the spawn site.