refactor(init): event-driven readiness + early-bind vsock + real PID1 reaper (issue #3)

[ZhiXiao-Lin]

The proper, structural fix for #3 (the recurring WARN Exec socket appeared but heartbeat failed / run -it Connection refused), plus the PID-1 reaper that the same area needs. Supersedes #14 (the interim 10s→30s budget bump): this removes that band-aid and replaces it with an event-driven, VM-liveness-bounded wait.

Why

On a slow/loaded cold boot, guest-init binds its exec (vsock 4089) and PTY (4090) servers only late in boot (after virtio-fs pivot, network bring-up, container spawn), so the bind could land past the host's fixed readiness budget → false warning + -it race. It can't bind earlier naively: spawn_isolated runs non-async-signal-safe code before exec, safe only because the parent is single-threaded at fork. Separately, guest-init (as PID 1) only waited on the container pid, so reparented orphans + the sidecar were never reaped.

What (3 commits)

P1 — bind early, serve late. Split exec/PTY servers into bind() (pure socket/bind/listen syscalls, on the main thread before the network + fork — fork-safe, fills the listen backlog so a host connect queues instead of being refused) and serve() (accept loop, spawned after the fork). Removes the -it "Connection refused".

P2 — event-driven, liveness-bounded readiness. Early binding makes the host connect succeed and heartbeat()'s (timeout-less) read block until the guest accepts, so wait_for_exec_ready is rewritten to bound each connect+heartbeat attempt, return at once when the VM exits (has_exited — fast-exit containers never stall), and use a large cap only as a backstop. A healthy guest passes the heartbeat the moment its accept loop runs, however slow the boot — no fixed budget to outrun. Also: dead /sbin/init → /bin/sh default + stale doc comment.

P3 — real PID 1 reaper. New reaper registry: handlers mark their child pid MANAGED across the spawn (lock held across fork closes the spawn/register race for fast-exiting commands); the supervision loop peeks exited children non-destructively with waitid(WNOWAIT) and routes — container → reap+propagate exit code; MANAGED → left for the handler (real exec/PTY codes preserved); orphans + sidecar → reaped here. Fixes the zombie leak without the waitpid(-1) race that would corrupt exec codes (an ECHILD'd handler reports exit 0).

Testing (real KVM + unit)

• Unit: ~2300 workspace lib tests pass (0 fail), incl. new reaper registry tests.
• Real-VM core_smoke: 12/14 pass (incl. interactive_pty, foreground_exit_code, lifecycle, pause/kill/wait, ports, compose, volumes); the 2 failures (network_connect_disconnect_before_start, restart_policy_monitor_recovers_dead_box) fail identically on the clean baseline — pre-existing, unrelated to this change. host_smoke command matrix passes.
• Issue WARN Exec socket appeared but heartbeat failed, exec will not be available #3 before/after: with a 15s boot delay, the old code emits the heartbeat failed warning at 10s and exec fails (Connection reset); this branch waits out the 17s boot, no warning, exec works.
• P3 exit codes (the risk): container exit 7→7; exec exit 42→42, false→1, true→0, exit 3→3 — no regression. Reaper keeps 0 zombies.

Honest caveat

I could not empirically reproduce the P3 zombie leak: shell-created orphans got reaped within the container tree (busybox ash reaps its subshell bg jobs) on both old and new code. P3 is architecturally correct (old code provably never waitpid(-1)s, so a genuine double-fork daemon's reparented grandchild + the sidecar would leak) and verified to not regress exit codes, but its practical impact is lower than the analysis implied. P2's fix is the high-value, verified one.

Built/verified on x86_64 Linux/KVM; the suite needs A3S_REGISTRY_MIRRORS (Docker Hub egress was blocked in the test env) and a3s-box-shim built in the same profile.