Serve gdb on the vCPU thread #1974

gdbstub runs on a separate thread and talks to the vCPU thread through two channels. That needs 12 request and 16 reply message kinds, a startup handshake that sends the interrupt handle, and a loop that watches both the channel and the socket.

Problems this causes on main:

• The stop-reason loop spins at 100% CPU while the guest runs. Each pass toggles O_NONBLOCK and peeks the socket (event_loop.rs#L85).
• Ctrl-C while the vCPU is not running, for example during a host call, ends the gdb session. on_interrupt returns a fatal error (event_loop.rs#L108).
• A sandbox from a running snapshot can be dropped before a client connects. Its gdb thread then stays blocked in accept() and holds the port forever (mod.rs#L305). Later sandboxes on that port only log an error and run without gdb.
• An unexpected disconnect leaves debugging enabled and int3 bytes in memory. The next debug exit fails the guest call. The docs say the guest continues (how-to-debug-a-hyperlight-guest.md#L29).
• If reporting a crash to gdb fails, the ? returns that debug error instead of the guest's error (hyperlight_vm/mod.rs#L798).
• The gdb thread's spawn result and errors are discarded (mod.rs#L301).

Proposal:

• The vCPU thread drives gdbstub's GdbStubStateMachine at each debug stop. gdbstub's Target is implemented on HyperlightVm, so requests call the VM directly. The message enums go away.
• HyperlightVm owns a GdbSession with the listener and the connection. Dropping the sandbox frees the port.
• The client is accepted at the first debug stop. A client may connect before the vCPU stops.
• A small watcher thread blocks in peek on a clone of the socket while the guest runs. On data it calls kill_from_debugger. This is the only extra thread.
• While stopped, the target holds clones of the HostSharedMemory handles. This avoids lifetimes and unsafe.

Draft result (not yet pushed): about 650 fewer lines. It passes all gdb tests on KVM, plus a new end-to-end Ctrl-C test. It fixes every problem above, #1973, and the rbx read in #1971.

Open questions:

• Attaching again after a detach (see Rethink debug lifecycle #1210).
• Moving the session to the new VM in Sandbox::recreate.