Perf follow-up: batched reads, stdin coalescing, iodata output

[nyo16]

Summary

Measurement-driven performance cycle from the 2026-08-31 perf reports
(perf-otp + perf-hotpath). Every phase was bench-gated: MIX_ENV=prod
medians, ≥3 runs, ~11% run-to-run spread as the noise floor, one change at
a time. Scenarios are committed in bench/perf.exs.

Also carries the previously uncommitted remainder of the 1.4.0
audit-remediation batch (c_src hardening, docs, CI) already described in
CHANGELOG 1.4.0.

Results (M1 Max, prod medians)

Metric	Before	After
16 MiB stdin as ~80-byte list elements	711 ms	30 ms (1.5× a single-binary write)
Same, lazy stream + input_buffer: 65_536	641 ms	33 ms (opt-in; default write-through unchanged)
run/2 vs stream! 64 MiB gap (output: :iodata)	~35% behind	~18% behind
All baseline metrics (spawn, throughput, stderr, 128-way)	—	within spread

Added

• Process.read_batch/3 / read_stderr_batch/3 — up to max_chunks
  pipe reads per GenServer round trip. A batch never waits once it has data
  (ends at first EAGAIN); EOF/error after ≥1 chunk is deferred to the next
  call. All four drain consumers (run/2, stream!/2, Daemon ×2) use it.
  read/2 is unchanged.
• :input_buffer opt (run/2, stream!/2) — opt-in coalescing for
  lazy stdin enumerables; default 0 keeps element-granular write-through
  (interactive/PTY stdin depends on it).
• output: :iodata opt (run/2) — skips the terminal
  IO.iodata_to_binary/1 flatten (a full-size alloc+copy for large
  outputs). Default :binary unchanged.

Changed

• Eager list :input coalesces into flat 1 MiB batches in the caller's
  process before any task closure captures it. Root cause of the 711 ms:
  Task.async closure capture copies a 200k-cons list (~20 ms) — and the
  run path crossed two task boundaries, paying it twice.
• Operations folded from four maps to two (monitor ref rides in the
  pending entry); multi-writer resume passes share one write budget with
  a deduplicated :continue_writes self-send — server occupancy no longer
  multiplies by parked-writer count (kill/2 during a 4×2 MiB fan-in
  replies <1 s, tested).
• stream!/2 may emit several ≤64 KiB chunks per resource step (sizes
  and ordering unchanged; noted in CHANGELOG as the only observable timing
  change).

Platform note

Read batching yields ~1-chunk batches on macOS (pipe capacity = read size;
probed: 941 calls / 1024 chunks). Kept on measured no-regression (−3–7% on
three metrics, tighter variance); the projected +30–40% applies to Linux's
1 MiB shepherd-grown pipes.

Verification

• mix test ×3 green (236 tests, 4 properties), mix credo --strict
  clean, --warnings-as-errors, formatted
• Reviewed by 3 parallel specialist agents — 0 blockers; all 10 warnings
  fixed in-branch (incl. a double-coalesce copy and Linux-vacuous test
  assertions)
• CI fixes included: 2 MiB fan-in payloads (1 MiB fit the Linux pipe
  exactly and never parked), busybox-safe parent-pid lookup, zombie-aware
  liveness probe for containerized runners, ExUnit in the dialyzer PLT