fix: recover from non-JSON lines in stdout stream

[esensible]

Summary

When non-JSON lines appear on stdout (e.g. verbose HTTP logs, sandbox debug messages, mTLS configuration output), the json_buffer accumulation logic in _read_messages_impl permanently poisons the buffer. Once any non-JSON content
enters the buffer, all subsequent json.loads() calls fail, causing the SDK to silently drop every remaining message.

In practice this manifests as query() returning incomplete results or the client hanging indefinitely.

• Root cause: _read_messages_impl unconditionally appends every stdout line to json_buffer. A non-JSON line like 2026-02-19 [DEBUG] configureGlobalMTLS starting gets concatenated with the next valid JSON object, producing
  unparseable content that persists for the lifetime of the stream.
• Fix: Try standalone json.loads() first (covers the common case of a complete JSON object on a single line). Only start buffering if the line starts with { (the stream-json protocol emits JSON objects). Non-JSON lines are logged
  at DEBUG level and skipped.

Fixes #347

Test plan

• Added test_non_json_lines_dont_poison_buffer — simulates non-JSON log lines interleaved with valid JSON messages
• Added test_non_json_lines_between_split_json — verifies non-JSON lines before a split JSON object don't corrupt the buffer
• All 158 existing tests pass
• ruff check, ruff format, mypy all clean
• Validated in production Lambda environment (non-JSON mTLS debug lines no longer cause hangs)

🤖 Generated with Claude Code