Investigate RPC codec Close/ReadHeader race on timed-out calls

The broader race run during #1652 found a race inside the pinned go-micro RPC client: bytes.Buffer.Reset in rpcCodec.ReadHeader (rpc_codec.go:229) races with readWriteCloser.Close (rpc_codec.go:88) via rpcStream.Close. The initiating path was agent.TestCommandExecutionLifecycle -> executeCommandRun -> service.CallDynamic; it uses a 100ms deadline and an intentionally waiting handler. The race was attributed to a later test because the RPC goroutine outlived the initiating call.

Pinned version: v6.13.1-0.20260910093304-a43bfe1d2c6e. Inspect client/rpc_client.go: the receive goroutine runs separately while timeout returns through deferred stream.Close. Need a bounded cancellation/close lifecycle that does not reuse/reset buffers concurrently. Keep dependency policy: Mu-local adapter or deliberate fork/vendor if needed, not a framework change justified solely by Mu.

Reproduce with go test ./agent -race -short (or targeted command lifecycle repetitions). Do not remove timeout coverage, add sleeps to conceal it, suppress the race, or describe a later passing run as proof it is fixed. Full regular short suite passed; this race remains unresolved.

Backlog cleanup — 18 September 2026

Canonical issue for this unresolved race. Duplicate #1761 records another occurrence in #1760's CI with the same dependency and call path. No fix or race verification was performed during backlog cleanup. Historical test commands above are diagnostic context; the current instruction remains not to run tests.

Start by reading client/rpc_client.go, especially the receive goroutine and deferred stream.Close, then inspect rpc_codec.go lines 88 and 229 and the agent.TestCommandExecutionLifecycle path. Do not run tests per the current instruction. Done means Close and ReadHeader no longer reset or access shared buffers concurrently, while timeout coverage and dependency policy remain intact.