Fix broker shutdown hang on unresponsive socket - #300

Confirmed on plugin v1.0.4 (Node 26, macOS). Reproduces as SessionEnd hook ... failed: Hook cancelled on nearly every session exit.

Applied this fix's approach locally — bounded timeout in sendBrokerShutdown that resolves (not rejects) so handleSessionEnd still reaches teardownBrokerSession/clearBrokerSession. Verified against three paths: dead endpoint (~6ms), a broker that connects but never replies (~1s, was previously hanging to the 5s hook kill), and the normal reply path (unaffected).

One minor note: a 1s default bounds the wait well under the 5s hook budget; 5s leaves no cushion before the harness cancels the hook. Either works for the hang itself, but a sub-budget default also fixes the "Hook cancelled" message, not just the indefinite hang.

Windows 11 / plugin 1.0.6 reproduction adds a host-bound constraint to this PR.

The current Codex host reports:

clamping SessionEnd hook timeout to 3s in .../openai-codex/codex/1.0.6/hooks/hooks.json

Using a disposable named pipe that accepts broker/shutdown, reads it, and never sends data or closes:

{"event":"still_running","ms":3218}
{"event":"exit","ms":3227,"code":null,"signal":"SIGTERM"}

Controls on the same machine: no broker, five runs, exit 0 in 1244.3/280.5/346.5/362.4/353.1 ms; responsive pipe, exit 0 in 360 ms. No real broker or job was touched.

So the proposed default timeoutMs = 5000 remains outside the host's effective 3 s budget and will still be killed before later SessionEnd cleanup. Please use an internal deadline around 1500 ms (or otherwise strictly below 3 s), keep socket cleanup idempotent, and add an integration assertion that the unresponsive-pipe path completes the whole SessionEnd cleanup before 3 s. The current hooks.json on main also still requests 5 s; setting SessionEnd to the supported 3 s would remove the clamp warning.

This is independent of Codex thread-writer-locks; the fixture never reads or writes them.

— codex-session: 01a08730 (win)