daemon: memory watchdog decides on current RSS, not lifetime peak - #2249

store_metrics_in_db materialized a Vec<String> of every re-serialized
event while the full Vec<MetricEvent> (each holding the redacted JSON
tree) was still alive -- two complete copies of a transcript batch
resident at once (git-ai-project#2244).

The stream worker now serializes each MetricEvent as it is built and
drops the tree immediately; persistence takes the pre-serialized rows
via the new persist_metric_jsons_blocking. Existing callers of
persist_metrics_blocking are unchanged (it now delegates to the same
insert path).

Behavior note: previously one unserializable event failed the whole
batch (all-or-nothing insert); the stream-worker path now drops the
failing event with a warning and persists the rest. These are
best-effort diagnostics, and partial persistence beats losing the
batch.

Part 2/7 of the git-ai-project#2244 fix stack (stacked on 1/7).

read_json_line buffered socket lines of unbounded length. Both daemon
sockets speak line-delimited JSON with bounded frames (trace2 events,
control request headers; checkpoint bodies travel separately after the
header line), so a runaway line can balloon daemon RSS past the memory
watchdog (git-ai-project#2244).

- Lines beyond MAX_SOCKET_LINE_BYTES (4 MiB) are discarded without
  being buffered (byte-based read_until + skip_until; read_line would
  turn a cap that slices a multi-byte character into InvalidData and
  drop the connection).
- The control loop ANSWERS an oversized request with an error response:
  silently eating it would stall the client until its socket timeout,
  after which it reconnects and resends the same request forever.
- The trace loop skips oversized frames and keeps reading.

Part 3/7 of the git-ai-project#2244 fix stack (stacked on 2/7).

The stream watermark was persisted only after a batch was converted
and stored. When batch processing OOM-aborts the daemon (memory
watchdog), the watermark is still at the batch start, so the respawned
daemon re-reads the same bytes and aborts again -- the abort loop
observed in production, 22 aborts in 5 days on one machine (git-ai-project#2244).

Transcript metrics are best-effort telemetry; losing one batch of
diagnostics on a crash is a safer failure mode than a crash loop that
blocks traced git commands. The watermark now advances immediately
after a batch is read.

Part 4/7 of the git-ai-project#2244 fix stack (stacked on 3/7).

The watchdog sampled getrusage ru_maxrss, a monotonic lifetime
high-water mark. One transient allocation spike therefore condemned
the process on every subsequent poll even after the memory was freed:
the daemon could only ever abort, never recover (git-ai-project#2244).

Decide on the CURRENT resident set size instead (proc_pidinfo on
macOS, /proc/self/statm on other unix, working set on Windows). The
emergency log carries both rss_bytes (decision input) and
peak_rss_bytes (context). Test-support env var names are unchanged;
the sample sequence now represents current-RSS values.

Tradeoff, stated explicitly: with 1 s polls, a workload that spikes
above the limit and frees within the poll interval is no longer
detected (the peak-based check caught the first spike ever). The
watchdog exists to stop sustained balloons, and an undetected
transient spike that the allocator survives is strictly better than a
guaranteed abort loop; the ingestion caps earlier in this stack bound
those transients at the source.

Part 5/7 of the git-ai-project#2244 fix stack (stacked on 4/7).