proto: fix daemon/engine attribution in two buffer-clamp descriptions

DAEMON's rebase audit caught it: TaskDetail.effectiveBufferBytes said "the
daemon reduces every live segment's buffer" to fit maxTotalBufferBytes, but
ADR 0011's ownership table (line 55) assigns bufferBytes/maxTotalBufferBytes
to CORE in bytes-units -- DAEMON counts tasks, CORE counts segments and
bytes. "The engine" is correct.

Same error, same root cause, in DownloadSpec.segments: "the daemon lowers it
to the per-host cap" attributes the per-host *segment* cap to DAEMON, but
that's CORE's (ADR 0011 line 54, "CORE enforces per-host segment caps -- it
owns the connections and is the only place segments are counted"). DAEMON's
own per-host cap is a *task*-level admission cap (line 50), a different
thing entirely -- conflating the two in the schema's own prose is exactly
how the clamp ends up implemented twice, once in each lane, disagreeing.

Description-only, no version bump: the JSON Schema shape is untouched, only
which component the prose names as doing the reducing. Regenerated code
diffs are comment-only (doc comments in the generated header and TS types).

Checked every other buffer/segment-clamp description for the same mistake;
the rest either already said "CORE"/"the engine" or used passive voice that
doesn't misattribute (Settings.connection.maxTotalBufferBytes,
Settings.connection.bufferBytes, docs/04, ADR 0012).

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

core/generated/velox_proto.hpp

@@ -533,7 +533,7 @@ struct DownloadSpec {
     std::optional<std::string> categoryId{};
     /// Required when startMode is 'queue'.
     std::optional<std::string> queueId{};
-    /// The REQUESTED connection count. An upper bound, not a promise: the daemon lowers it to the
+    /// The REQUESTED connection count. An upper bound, not a promise: the engine lowers it to the
     /// 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{};
@@ -835,7 +835,7 @@ struct TaskDetail {
     /// 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
+    /// the engine 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.