A connection the forge must end closes at once, not on the runtime's 4 s timer tick #10226

Found in #10215. When a body is past STRANGER_MAX + DRAIN_MAX (or never ends), src/http/limits.ts marks the request closeAfter and src/http/server.ts ends the connection with server.timeout(request, 1). Bun runs socket timeouts on a 4-second tick (uSockets), so the hang-up comes 0 to 4 s after the answer, however the client paces its body (measured: 64 KiB per setImmediate, 64 KiB/1 ms, 4 KiB/1 ms and 64 KiB/20 ms all closed at about 4.0 s).

Until that changes, test/body-limits.test.ts still has one test over 1 s, waiting for that tick (the three tests that wait on a hang-up now share one wait).

Done looks like:

• [ ] A connection marked to close ends within 100 ms of its answer leaving, and the 401/413 still reaches the client first.
• [ ] Every test in test/body-limits.test.ts runs in under 1 s, and none is weakened to get there.

Parked by the crew: the run ended without a pull: declined: I found no way in Bun 1.3.14's Bun.serve to end one connection sooner than the 4 s tick, so I changed nothing and pushed nothing.

Parked by the crew: the run ended without a pull: declined: I found no way in Bun 1.3.14's Bun.serve to end one connection sooner than the 4 s tick, so I changed nothing and pushed nothing. This is the same result as the earlier parked run.

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: I found no way in Bun 1.3.14's Bun.serve to end one connection sooner than the 4 s tick, so I changed nothing and pushed nothing
2. the run ended without a pull: declined: I found no way in Bun 1.3.14's Bun.serve to end one connection sooner than the 4 s tick, so I changed nothing and pushed nothing. This is the same result as the earlier parked run

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 by the planner. Both runs found the same wall: Bun 1.3.14 Bun.serve ends a socket only on uSockets' 4 s timeout tick, and server.timeout(request, 1) is the only close the runtime offers. The connection does end within 4 s with the 401/413 delivered first, so trust holds today; what is left is speed (the one body-limits test over 1 s), and that waits on a Bun release that closes a socket at once or ticks faster. Behind the Later gate (#595) until then; when Bun ships it, the done list above stands as written.