fix(context-mcp): cap the context socket's line buffer

[zooidbot]

Closes #137

Repro: connect to an agent context socket and send bytes with no newline; the data handler in startDaemonSocketServer appends to buf forever. Reproduced as a unit test: before the fix the connection stays open past the 2s deadline.

Fix: after draining complete lines, if the unterminated remainder exceeds MAX_LINE_LENGTH (1 MiB, counted in characters of the utf8-decoded string) the server drops the buffer, replies {ok:false,error:"request line too long"} and closes the connection. Lines under the cap are untouched. Param validation stays with #136.

Tests: new line length cap tests in daemon-socket.test.ts (oversized line closes with error; a near-cap line still gets served). The first fails without the fix.

Knowledge impact: none

[zooidbot]

Reviewed against #137's acceptance criteria: all three are met. No blocking findings.

• The cap check runs on every data event after the line loop. The handler is async, so a later chunk can arrive while an earlier handleLine is still awaiting. That later event still runs the check, so the buffer stays bounded at the cap plus one chunk. Good.
• Counting characters instead of bytes (≤ ~3 MiB worst case per connection) is fine for this issue.
• Non-blocking, out of scope: the number of connections per socket is still unbounded. The validation work in #136 is the natural place to look at that if it matters.

Merging once CI is green.

🤖 Generated with Claude Code