proto: land B4 and B2a — buffer bounds, budget knobs, effective readback (1.1.0)

Minor bump on 1.0.0, per core/docs/buffer-sizing.md.

B4 — bufferBytes bounds corrected in all four locations (DownloadSpec,
TaskDetail, download.update's patch, Settings.connection.bufferBytes): was
4 KiB-8 MiB with no stated default, now 64 KiB-16 MiB with a 1 MiB default.
64 KiB because 4 KiB is smaller than one libcurl HTTP/2 write-callback delivery;
16 MiB because throughput from write size is flat past ~1-4 MiB and past 16 MiB
there is stall-cover left to buy but no memory left to spend it on; 1 MiB
default because it is the only candidate for which docs/04's 60 MB RSS target
actually holds once buffers are counted per segment, not per download.

Two new settings keys: connection.maxTotalBufferBytes (128 MiB default) and
connection.maxActiveSegments (32 default). Without them CORE's clamp — reduce
every live segment's buffer to fit the global cap — has no wire configuration
surface, and "20 active downloads" has no meaning distinct from 160 live TLS
connections.

B2a — TaskDetail.effectiveBufferBytes: what a segment is actually using right
now, after the clamp. Placed on TaskDetail next to bufferBytes, following the
requested/effective pattern ADR 0010 already established for segments. The
download.get fixture now demonstrates a real clamp (16 MiB requested, 4 MiB
effective) rather than a case where the cap happens not to bind.

docs/04-engine-design.md §4 and §8 updated in the same change per CORE's
request and CLAUDE.md rule 5: the RSS target is now stated as conditional on
maxActiveSegments = 32, and the old 4 MiB/64 MiB/256 MiB numbers are corrected
to match the schema. ADR 0012 records the reasoning and explicitly keeps the
60 MB target over CORE's offered 120 MB alternative, with the arithmetic that
makes 60 MB achievable with margin.

Numbered 0012 rather than 0011: DAEMON is independently drafting ADR 0011
(admission control / segment budget split) in a peer session at time of
writing, so 0011 was reserved to avoid a collision.

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

contracts/fixtures/download.get.json

@@ -116,7 +116,8 @@
       "referrer": "https://releases.ubuntu.com/26.04/",
       "userAgent": "Velox/0.1",
       "mime": "application/octet-stream",
-      "bufferBytes": 4194304,
+      "bufferBytes": 16777216,
+      "effectiveBufferBytes": 4194304,
       "partPath": "/home/sami/Downloads/Programs/ubuntu-26.04-desktop-amd64.iso.veloxpart",
       "checksum": null,
       "checksumVerified": null,
@@ -128,6 +129,7 @@
     "segment ranges are contiguous and cover exactly [0, sizeBytes) with no gaps or overlaps",
     "startByte and endByte are both INCLUSIVE: segment 0 here covers 778567680 bytes, 0 through 778567679, and is copied verbatim into 'Range: bytes=0-778567679'",
     "segmentDetail has exactly summary.segments entries",
-    "the GUI draws one bar per entry and is never told what a segment steal is"
+    "the GUI draws one bar per entry and is never told what a segment steal is",
+    "bufferBytes is what was requested (16 MiB); effectiveBufferBytes (4 MiB) is what this segment is actually using right now, after connection.maxTotalBufferBytes (128 MiB default) is divided across every live segment in the daemon -- not just this task's -- up to connection.maxActiveSegments (32 default). The clamp is global: a task can be reduced even when its own segment count alone would not force it."
   ]
 }

contracts/fixtures/settings.get.json

@@ -9,6 +9,8 @@
       "keys": [
         "connection.maxSegmentsPerDownload",
         "connection.bufferBytes",
+        "connection.maxTotalBufferBytes",
+        "connection.maxActiveSegments",
         "connection.maxConcurrentDownloads",
         "connection.timeoutSec"
       ]
@@ -20,7 +22,9 @@
     "result": {
       "values": {
         "connection.maxSegmentsPerDownload": 8,
-        "connection.bufferBytes": 4194304,
+        "connection.bufferBytes": 1048576,
+        "connection.maxTotalBufferBytes": 134217728,
+        "connection.maxActiveSegments": 32,
         "connection.maxConcurrentDownloads": 5,
         "connection.timeoutSec": 30
       }
@@ -29,6 +33,8 @@
   "assertions": [
     "only the requested keys come back",
     "keys null returns everything",
-    "no password is ever present: credentials live in the Secret Service"
+    "no password is ever present: credentials live in the Secret Service",
+    "connection.bufferBytes defaults to 1 MiB (1048576), not the old 4 MiB",
+    "connection.maxTotalBufferBytes and connection.maxActiveSegments are the two knobs behind TaskDetail.effectiveBufferBytes; Options cannot show or set the clamp without them"
   ]
 }

contracts/fixtures/settings.set.json

@@ -8,7 +8,8 @@
     "params": {
       "values": {
         "connection.maxSegmentsPerDownload": 16,
-        "downloads.verifyChecksums": true
+        "downloads.verifyChecksums": true,
+        "connection.bufferBytes": 2097152
       }
     }
   },
@@ -18,17 +19,20 @@
     "result": {
       "values": {
         "connection.maxSegmentsPerDownload": 16,
-        "downloads.verifyChecksums": true
+        "downloads.verifyChecksums": true,
+        "connection.bufferBytes": 2097152
       },
       "changed": [
         "connection.maxSegmentsPerDownload",
-        "downloads.verifyChecksums"
+        "downloads.verifyChecksums",
+        "connection.bufferBytes"
       ]
     }
   },
   "assertions": [
     "event.settings.changed is emitted carrying exactly the keys in changed[]",
     "an unknown key is -32602 and nothing at all is written",
-    "a directory key naming an unwritable path is -32011"
+    "a directory key naming an unwritable path is -32011",
+    "connection.bufferBytes accepts 64 KiB - 16 MiB; a value outside that range is -32602"
   ]
 }