core: redo bufferBytes default and RSS reconciliation (per-segment)

First pass counted one buffer per download; it is one per segment. 20
active downloads at the default 8 segments = 160 buffers, so at 20 tasks
the binding constraint is the global cap, not the per-segment default —
256 MiB and the "<=60 MB RSS / 20 downloads" target (line 125) cannot both
hold whatever the default is.

Floor (64 KiB) and ceiling (16 MiB) unchanged — the 256/64 unreachability
argument is stronger under per-segment accounting. Changes:
 - default 1 MiB (was 2): with the cap below, 32 live segments x 1 MiB =
   32 MiB buffers -> ~45-50 MiB RSS, line 125 holds with margin.
 - NEW maxActiveSegments (default 32): a global concurrent-segment cap is
   the actual mechanism that bounds "20 active downloads"; docs/01 §2
   implies it, docs/04 never states it. Without it no buffer policy hits
   60 MB.
 - maxTotalBufferBytes 128 MiB (was 256) and it must be ADDED to the
   contract — currently absent, so the clamp CORE implements has no wire
   representation and Options can't show/set it. Folded into B2a.
 - line 125: keep 60 MB "given maxActiveSegments=32 and default buffers",
   or explicitly raise to 120 MB — ADR records which. Flagged that
   changing it is a defensible outcome CORE owns, not a number that
   quietly loses.
 - bufferBytes bounds are in FOUR schema files, not three:
   Settings.schema.json connection.bufferBytes also has 4096-8388608.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HPPSGhiArbvQgwC2DNiURS

core/docs/proto-requests-m1.md

@@ -82,6 +82,15 @@ extension; it has to be in the schema or it's dropped by every conformance repla
 and placement are PROTO's call (`effectiveBufferBytes` on `TaskSummary` / `TaskDetail`,
 or a dedicated readback). Land it whenever — it just can't be improvised later.
 
+Fold in two more, all discovered via B4 (`buffer-sizing.md`):
+- **`maxTotalBufferBytes` is absent from the contract entirely.** CORE implements the
+  clamp against it; the Options dialog can neither show nor set it. Add
+  `Settings.schema.json connection.maxTotalBufferBytes` (recommended default
+  `134217728` = 128 MiB).
+- **`maxActiveSegments` is new** — the global concurrent-segment cap that actually bounds
+  "20 active downloads" for the RSS budget. Add `Settings.schema.json
+  connection.maxActiveSegments` (recommended default `32`). DAEMON's scheduler reads it.
+
 ### B3. Freeze `Segment.schema.json` field names
 
 `Segment` is already on PROTO's type list (`contracts/README.md`) and `TaskDetail`
@@ -128,12 +137,15 @@ total length 0 round-trips. Flag back if the chosen fix needs anything else from
 
 ### B4. `bufferBytes` range is wrong in the frozen schema — *see `buffer-sizing.md`*
 
-`contracts/` froze `bufferBytes` at 4 KiB – 8 MiB; `docs/04` §4 says 64 KiB – 64 MiB
-default 4 MiB; the RSS DoD (`docs/04` §8) can't hold either default. CORE's analysis and
-the recommended range (**64 KiB – 16 MiB, default 2 MiB**, `max_total_buffer_bytes`
-unchanged at 256 MiB) with the global-cap arithmetic is in
-[`core/docs/buffer-sizing.md`](buffer-sizing.md). PROTO to land schema + `docs/04` §4 +
-ADR together.
+`contracts/` froze `bufferBytes` at 4 KiB – 8 MiB **in four schema files** (`DownloadSpec`,
+`TaskDetail`, `download.update` patch, and `Settings.schema.json connection.bufferBytes`);
+`docs/04` §4 says 64 KiB – 64 MiB default 4 MiB; the RSS DoD (`docs/04` §8 line 125) holds
+with neither. CORE's recommendation — **64 KiB – 16 MiB, default 1 MiB**, plus a new
+**`maxActiveSegments` (32)** global concurrent-segment cap and **`maxTotalBufferBytes`
+lowered to 128 MiB** and *added to the contract*, with line 125 kept at 60 MB "given
+`maxActiveSegments = 32`" (or explicitly raised to 120 MB) — and the per-segment RSS
+arithmetic are in [`core/docs/buffer-sizing.md`](buffer-sizing.md). PROTO to land the four
+schema edits + `docs/04` §4 + §8 + ADR together.
 
 ---