Length-prefixed IPC framing: a write error after a frame's first byte must close the channel, not send an error reply

Protocol: each message is a JSON header line, optionally carrying binLength, followed by that many binary bytes (newline-JSON plus a binary tail, over a pipe or fd).

Bug: a non-EPIPE write error (EIO, for example) partway through a frame was caught higher up, and the server then sent a normal {id, error} reply. The client had already parsed the header and was waiting for binLength bytes, so it swallowed the error reply as binary. Every later frame was misaligned, and the request hung.

Fix: count the bytes written for the current frame in the write loop. - If the error happens before the first byte, re-throw; the stream is still framed, so an error reply is safe. - After the first byte, the stream can't be recovered: log to stderr and exit (or close the fd) so the client sees EOF and fails cleanly.

Testing: - Add a fault hook that fails the k-th frame after its header line. Assert the server exits non-zero and the client never parses a bad frame. - Have the client's frame parser count parse failures instead of crashing the test. - Read test hooks from the environment once at startup, not on every write.