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

core/generated/velox_proto.hpp

@@ -3,7 +3,7 @@
 //
 // Source:    contracts/schema/**
 // Generator: contracts/codegen/gen_cpp.py
-// Contract:  v1.0.0
+// Contract:  v1.1.0
 //
 // Hand-editing this file is a merge blocker. Fix the schema and regenerate:
 //     python3 contracts/codegen/gen_cpp.py
@@ -27,7 +27,7 @@
 // docs/adr/0009-generated-protocol-library.md.
 namespace velox::proto {
 
-inline constexpr std::string_view kProtocolVersion = "1.0.0";
+inline constexpr std::string_view kProtocolVersion = "1.1.0";
 
 /// Why a payload could not be turned into a typed value. `path` is a JSON Pointer
 /// into the offending document, so a conformance failure names the exact field.
@@ -219,6 +219,8 @@ enum class SettingKey {
     ConnectionPreset,  // "connection.preset"
     ConnectionMaxSegmentsPerDownload,  // "connection.maxSegmentsPerDownload"
     ConnectionBufferBytes,  // "connection.bufferBytes"
+    ConnectionMaxTotalBufferBytes,  // "connection.maxTotalBufferBytes"
+    ConnectionMaxActiveSegments,  // "connection.maxActiveSegments"
     ConnectionMaxConcurrentDownloads,  // "connection.maxConcurrentDownloads"
     ConnectionTimeoutSec,  // "connection.timeoutSec"
     ConnectionMaxRetries,  // "connection.maxRetries"
@@ -535,6 +537,9 @@ struct DownloadSpec {
     /// per-host cap, and to 1 when the source turns out not to be resumable. What is actually in
     /// use comes back as TaskSummary.segments. null means use connection.maxSegmentsPerDownload.
     std::optional<std::int64_t> segments{};
+    /// Requested write buffer per segment, in bytes. null means use connection.bufferBytes. Default
+    /// 1 MiB; range 64 KiB - 16 MiB. Silently reduced to fit connection.maxTotalBufferBytes across
+    /// all live segments; the effective value is reported back as TaskDetail.effectiveBufferBytes.
     std::optional<std::int64_t> bufferBytes{};
     std::optional<StartMode> startMode{};
     std::optional<std::string> description{};
@@ -708,6 +713,9 @@ struct Settings {
     std::optional<bool> saveTo_createSubfolderPerSite{};
     std::optional<SettingsConnectionPreset> connection_preset{};
     std::optional<std::int64_t> connection_maxSegmentsPerDownload{};
+    /// Default per-segment write buffer, in bytes, when a task does not request its own. Default 1
+    /// MiB (1048576); range 64 KiB - 16 MiB. This is the single biggest throughput knob and is
+    /// exposed in Options -> Downloads -> 'Write buffer per connection'.
     std::optional<std::int64_t> connection_bufferBytes{};
     std::optional<std::int64_t> connection_maxConcurrentDownloads{};
     std::optional<std::int64_t> connection_timeoutSec{};
@@ -729,6 +737,17 @@ struct Settings {
     std::optional<std::string> sounds_onComplete{};
     std::optional<std::string> sounds_onQueueComplete{};
     std::optional<std::string> sounds_onError{};
+    /// Global cap on write-buffer memory across every live segment, in bytes. Default 128 MiB
+    /// (134217728). Every live segment's buffer is reduced to fit maxTotalBufferBytes / (live
+    /// segment count, capped at maxActiveSegments); the reduced value is reported per task as
+    /// TaskDetail.effectiveBufferBytes. Exists so a burst of large downloads with a large
+    /// per-segment buffer cannot exhaust memory.
+    std::optional<std::int64_t> connection_maxTotalBufferBytes{};
+    /// Global ceiling on segments actually transferring at once, across every task. Default 32.
+    /// This is the real bound behind '20 active downloads': the rest of each download's segments
+    /// queue rather than all dialling out simultaneously. DAEMON's scheduler needs this value to
+    /// decide what to admit; CORE enforces it.
+    std::optional<std::int64_t> connection_maxActiveSegments{};
 };
 
 /// Why a task is in the failed or retry_wait state. Distinct from the JSON-RPC Error, which
@@ -805,7 +824,15 @@ struct TaskDetail {
     std::optional<std::string> referrer{};
     std::optional<std::string> userAgent{};
     std::optional<std::string> mime{};
+    /// The REQUESTED write buffer per segment. See effectiveBufferBytes for what is actually in
+    /// use.
     std::optional<std::int64_t> bufferBytes{};
+    /// The write buffer actually in use per live segment, right now. May be well below bufferBytes:
+    /// the daemon reduces every live segment's buffer to fit connection.maxTotalBufferBytes across
+    /// connection.maxActiveSegments concurrently-transferring segments, and reports the reduced
+    /// value here so the GUI can show '16 MiB (using 4 MiB)'. null before the task has started its
+    /// first segment.
+    std::optional<std::int64_t> effectiveBufferBytes{};
     /// Absolute path of the .veloxpart file while the task is unfinished.
     std::optional<std::string> partPath{};
     std::optional<Checksum> checksum{};
@@ -1030,6 +1057,8 @@ struct DownloadUpdateParamsPatch {
     /// as DownloadSpec.segments. Takes effect on the next start; a running task is not re-segmented
     /// underneath the user.
     std::optional<std::int64_t> segments{};
+    /// The REQUESTED write buffer per segment. Subject to the same maxTotalBufferBytes reduction as
+    /// DownloadSpec.bufferBytes; the effective value comes back on the next download.get.
     std::optional<std::int64_t> bufferBytes{};
     std::optional<Checksum> checksum{};
 };