so101 serve boots with the arm unplugged: /status says "arm: not connected", cameras and the grow box keep serving #617

so101 serve now starts and listens when the arm is unplugged. When the port is missing or can't be opened, it logs arm not connected (<path>: <reason>) and keeps serving. That covers --port, SO101_PORT and detection.

I ran the new test, server.test.ts, stations.test.ts, readme.test.ts, cli-node.test.ts and fake-serve.test.ts, and they pass. tsc --noEmit reports errors in other files, but none in the three I changed.

• Without an arm:

- GET /status answers 200 with arm: "not connected" and no joints. - /version, /camera-profile and /grow/* answer as before. - Every route that needs the servos answers 503 {"error":"arm not connected"} before touching anything. - STOP, resume and E-stop still answer 200, and E-stop skips the bus hold. - The gain-sync timer doesn't start.

• Code: startServer now takes the bus or null. The route lists and the stand-in bus are in the new src/absent-bus.ts; openArm in src/cli.ts does the opening.
• Test: src/absent-arm.test.ts starts the server with no bus. It reads the case lines of server.ts and requires each route to be in exactly one of the arm-route or free-route lists. A new route must therefore be classified, or the test fails. It then checks every arm route answers 503.
• README: the Pi section now says the arm server runs unplugged.

• Drive stream is not a 503: /follow is accepted and closed at once with code 1013 and the reason arm not connected. Bun here never delivered a 503 written to an upgrade socket, so I used the same close-after-connect route the E-stop and hold already take.
• Detection no longer waits: serve with no port set used to block until a servo board appeared (waitForArm). It now starts without one. I removed that import from cli.ts and left the helper in place, since stations.test.ts still uses it. I also rewrote the README line that described the wait.
• Restart needed to connect: plugging the arm in needs a service restart, as the issue says (reconnecting is the next issue).
• Test teardown: the new test doesn't await server.close(). In this Bun, http.close never finishes after the server has closed a WebSocket. An E-stop close does the same on the armed server, so it isn't new.

Closes #615

so101 serve now starts and listens when the arm is unplugged. When the port is missing or can't be opened, it logs arm not connected (<path>: <reason>) and keeps serving. That covers --port, SO101_PORT and detection.

I ran the new test, server.test.ts, stations.test.ts, readme.test.ts, cli-node.test.ts and fake-serve.test.ts, and they pass. tsc --noEmit reports errors in other files, but none in the three I changed.

• Without an arm:

- GET /status answers 200 with arm: "not connected" and no joints. - /version, /camera-profile and /grow/* answer as before. - Every route that needs the servos answers 503 {"error":"arm not connected"} before touching anything. - STOP, resume and E-stop still answer 200, and E-stop skips the bus hold. - The gain-sync timer doesn't start.

• Code: startServer now takes the bus or null. The route lists and the stand-in bus are in the new src/absent-bus.ts; openArm in src/cli.ts does the opening.
• Test: src/absent-arm.test.ts starts the server with no bus. It reads the case lines of server.ts and requires each route to be in exactly one of the arm-route or free-route lists. A new route must therefore be classified, or the test fails. It then checks every arm route answers 503.
• README: the Pi section now says the arm server runs unplugged.

• Drive stream is not a 503: /follow is accepted and closed at once with code 1013 and the reason arm not connected. Bun here never delivered a 503 written to an upgrade socket, so I used the same close-after-connect route the E-stop and hold already take.
• Detection no longer waits: serve with no port set used to block until a servo board appeared (waitForArm). It now starts without one. I removed that import from cli.ts and left the helper in place, since stations.test.ts still uses it. I also rewrote the README line that described the wait.
• Restart needed to connect: plugging the arm in needs a service restart, as the issue says (reconnecting is the next issue).
• Test teardown: the new test doesn't await server.close(). In this Bun, http.close never finishes after the server has closed a WebSocket. An E-stop close does the same on the armed server, so it isn't new.