A sandboxed agent can run this repository's tests: unix sockets and loopback ports in its own temp directory, with the boundary kept #1107

A forge agent cannot see its own gate green before it pushes. Inside the crew sandbox, the forge's test servers listen on unix sockets, and the sandbox refuses the bind; every agent that tried to run bun test on this repository today said the same thing in its own words — "I ran the socket-using tests with the sandbox off, because the sandbox blocks listening on a unix socket" — and then, having found the door, pushed through it too. The door is shut now (trevato-apps/forge#21: no command runs outside the sandbox on request), which is right, and leaves the crew blind on this one repository: it can run tsc, it can run the tests that never open a socket, and it has to push the rest to the check.

Done looks like:

• [ ] Inside the sandbox, a run can bind unix sockets (and loopback TCP ports) under its own temp directory, so bun test over this repository's test/ runs as it does on a developer's machine. Claude Code's sandbox settings carry allowLocalBinding; find whether unix-socket binding has a setting on Linux (the docs leave it unsaid) or whether the forge's test server should fall back to a loopback port when a socket cannot be bound (FORGE_TEST_SOCKET=port), and do the one that keeps the boundary.
• [ ] test/crew-sandbox.test.ts proves it: a sandboxed run starts a server on a unix socket in tmpDir, reaches it, and is still refused localhost outside the sandbox and every path in denyRead.
• [ ] The crew brief for a repository whose tests need sockets no longer suggests leaving the sandbox; the agent is told what it can run and what the check will run for it.

Files I expect: src/crew/claude.ts (settings), src/crew/sandbox.ts, the test helpers that pick a socket path (test/helpers/*), docs/CREW.md.