environmentd: bound HTTP and SUBSCRIBE output buffering to prevent OOM (SQL-428, SQL-423)

[mtabebe]

Problem:

A single query can drive environmentd to OOM, even when the client read as
fast as it could, because two paths buffered unbounded output in the shared
process.

• HTTP SELECT. The peek path already streams results out of the replica in
  bounded batches, but the HTTP SQL layer re-buffered every batch into a
  serde_json::Value tree roughly 10-15x the wire size. A large SELECT over
  /api/ws or /api/sql grew memory without limit. The /api/sql size guard
  was a stale TODO and was never enforced.
• SUBSCRIBE / COPY-TO. The replica -> controller -> coordinator response path
  is unbounded at every hop, and the subscribe producer runs on the
  non-blockable coordinator main loop, so it cannot apply backpressure to a slow
  client. One slow or stopped SUBSCRIBE consumer could make the coordinator
  buffer the entire subscribe output in memory.

Solution:

HTTP SQL layer (SQL-428).

• WebSocket /api/ws streams rows straight through. SELECT now flows through a
  new StatementResult::Rows variant whose sender emits Rows(desc) plus
  per-row Row messages, flushing between stash batches so a slow client applies
  backpressure and only one batch is resident. max_result_size is enforced
  incrementally. Large results over WebSocket now get the same bounded memory
  profile as pgwire SELECT.
• Plain JSON /api/sql is a single buffered document. Rows are accumulated as
  pre-serialized RawValues instead of a Value tree, and max_result_size is
  enforced on the actual serialized byte count. An oversized result fails fast
  with ResultSize.
• MCP and prometheus consumers of SqlResult::Rows parse each RawValue on
  demand.

SUBSCRIBE / COPY-TO buffer (SQL-423).
Bound the terminal buffer and retire the sink when it overflows. ActiveSubscribe
carries a shared byte counter and a per-sink budget. Each send adds the batch's
byte size and a receiver wrapper subtracts it as the client writer drains, so the
counter tracks the currently buffered depth. After each response the coordinator retires the subscribe if the depth exceeds the budget, surfacing AdapterError::SubscribeFellBehind
with a hint to use a non-buffering client or COPY (SUBSCRIBE ...) TO STDOUT.

The budget is a new dyncfg subscribe_max_buffered_bytes (default 128 MiB).
COPY (SUBSCRIBE ...) TO STDOUT shares the channel and is covered too.

Testing:

New integration tests in src/environmentd/tests/server.rs:

• test_ws_select_streams_rows: a SELECT over /api/ws emits one Row message
  per row before CommandComplete, confirming the non-buffering path.
• test_http_sql_result_size_limit: with max_result_size lowered to 1 MB, an
  oversized /api/sql result fails with a result-size error while a small one succeeds.
• test_subscribe_buffer_bound: with subscribe_max_buffered_bytes set to 1 KiB,
  a COPY-wrapped SUBSCRIBE whose client never reads surfaces the "fell behind"
  error instead of growing without bound.