so101 server: hang up after answering 413 at the body cap #602

The so101 server now answers a request that goes over the body cap with 413, connection: close, and then hangs up the socket. A client can no longer keep sending on that connection.

• Fix: in Software/so101/src/server.ts, readBody no longer calls req.destroy() when the cap is hit. It pauses reading instead, and the catch handler writes the 413 with connection: close and destroys the socket once the response has gone out. The destroy-first version could have cut off the 413 itself.
• Test: I added a raw-socket test to light-endpoint.test.ts. It posts 1.5 MB to /grow/light and asserts that the response is 413, that it carries connection: close, and that the socket closes.
• Run results: light-endpoint.test.ts passes (6 tests). In src/server* tests, one fails: server.test.ts expects /vendor/three/build/three.module.js to return 200 and gets 404. I didn't touch the vendor route; I didn't run it on the base branch, so I can't say whether it fails there too.
• Type check not run: bun x tsc --noEmit can't run in the sandbox because it can't find the bun type definitions, so the type check is unverified here.

Closes #600

The so101 server now answers a request that goes over the body cap with 413, connection: close, and then hangs up the socket. A client can no longer keep sending on that connection.

• Fix: in Software/so101/src/server.ts, readBody no longer calls req.destroy() when the cap is hit. It pauses reading instead, and the catch handler writes the 413 with connection: close and destroys the socket once the response has gone out. The destroy-first version could have cut off the 413 itself.
• Test: I added a raw-socket test to light-endpoint.test.ts. It posts 1.5 MB to /grow/light and asserts that the response is 413, that it carries connection: close, and that the socket closes.
• Run results: light-endpoint.test.ts passes (6 tests). In src/server* tests, one fails: server.test.ts expects /vendor/three/build/three.module.js to return 200 and gets 404. I didn't touch the vendor route; I didn't run it on the base branch, so I can't say whether it fails there too.
• Type check not run: bun x tsc --noEmit can't run in the sandbox because it can't find the bun type definitions, so the type check is unverified here.

I merged main into the branch and pushed it (102e03f). light-endpoint.test.ts passes after the merge (6 tests). I didn't run the other suites or the type check.

main had already fixed the same thing in server.ts: it stops reading at the cap and sets connection: close on a 413. It also rewrote the body-cap test in light-endpoint.test.ts to flood a raw socket. Both conflicts resolved to main's version, so my server.ts change and my own raw-socket test are gone.

What this branch now adds on top of main is one assertion in the flood test: the 413 reply must contain connection: close. The earlier server.test.ts failure on /vendor/three/build/three.module.js is unchanged by this merge, and I haven't re-checked it.

I didn't fix anything for this failure, because I think it's a flaky test rather than something this pull broke. I pushed an empty commit (601d7db) to re-run the preview deploy.

The failing test is stop.test.ts, case (a): random drag/STOP/resume sequences with real sleeps, and a 5.9 s run time in the deploy log. This pull changes none of that code. Its only change to the tests is one extra assertion in light-endpoint.test.ts, which passes.

I ran stop.test.ts alone three times and all 8 tests passed each time. The deploy failed while running 158 test files together, so a timing problem under load is the likeliest cause. The log doesn't show which assertion in case (a) failed, so I can't confirm that. If the re-run fails on the same test, it needs its own fix, either a wider timing margin or a look at whether a real race is hiding there.