Sidecar protocol hardening: response-id correlation + health-check lock race

From the multi-agent Windows-robustness audit.

1. No response-id validation (src/sidecar/manager.rs request): the response envelope's id is never checked against the request id. Any code path that abandons an exchange mid-stream desyncs the protocol and hands a stale frame to the next caller. The request-timeout fix ([SIDECAR-REQUEST-TIMEOUT]) poisons the transport on timeout, which removes the known abandonment path, but defense-in-depth wants response.id == id verified, with a hard reconnect on mismatch.

2. Health-check TOCTOU (src/sidecar/manager.rs health_loop): the loop try_locks the transport, drops the guard, then calls health_check — a request can grab the transport in between, making the 2s ping race a slow-but-healthy request. Also "a busy lock proves the sidecar is alive" only proves a request is in flight, not that it is progressing (now mitigated by per-request budgets, but the monitor could track lock-hold duration instead of skipping).

Start in src/sidecar/manager.rs, reading the request and health_loop functions together with the transport locking and timeout behavior described in the issue. Trace how request IDs and the transport guard are handled, then verify that mismatched responses trigger reconnect behavior and that health checks cannot race with requests or mistake a stalled request for a healthy sidecar.