Self-deploy, step 3: a green release swaps in by handing over the listening socket, health read before the old process stops, the old one kept on failure

Split from #1432.

Done looks like:

[ ] The running forge starts the new process from releases/<sha>/ with the listening socket handed over (SO_REUSEPORT on the port, or fd passing on the unix socket; the pull says which and why), reads /api/v1/health from it, and only then drains itself as a restart does today.
[ ] A new process that is not healthy within its budget is stopped; the old keeps serving; one loud line on the lane and a comment on the landed pull.
[ ] test/release-swap.test.ts in GATE: a stand-in forge swaps with zero failed requests from a client looping through the swap; an unhealthy release leaves the old sha serving. (If the sandbox cannot run it, it is skipped there and named as skipped, like the other socket suites.)
[ ] Does not touch the platform path: that retires in a later step once landings have rolled this way for a week.

Self-deploy, step 3: a green release swaps in by handing over the listening socket, health read before the old process stops, the old one kept on failure #1663