[b7r6]

What and why

buf_channel: widen in-flight buffer 2 -> 32 to avoid write-stall resets

The buf channel between "read from client" and "write to store" held only 2
chunks (an explicitly-arbitrary magic number). During a large ByteStream.Write
forwarded to a slow shard CAS, that near-zero buffer stalls the producer the
instant the consumer lags, which stops the server draining its inbound stream,
empties the HTTP/2 flow-control window, and resets the connection mid-stream —
dropping multi-GiB toolchain uploads. Name it a const and widen to 32; tokio's
bounded channel doesn't preallocate, so the capacity costs memory only while
data is actually queued (exactly during a downstream stall).

Complements the transport-error -> Unavailable coding fix (5de7c28) and the
HTTP/2 adaptive-window server config.

Two filesystem_store tests (file_continues_to_stream_on_content_replace_test,
file_gets_cleans_up_on_cache_eviction) relied on the old 2-slot capacity to
keep the store's get() stalled with the file open after the reader took one
byte; with a 10-byte value and read_buffer_size 1 the whole blob now fits in
the channel, get() finishes, and the temp file is gone before the assertion.
They now stream a 100-byte value, which is longer than the channel holds.

How was this verified?

The branch's own tests, run with Bazel on railgun today after the rebase onto upstream b01417643e; CI on this PR is the first automated run.

Also part of the soak branch (#73): upstream HEAD plus every pending fix, run through the railgun fleet for an hour of continuous remote builds with no errors.

Risk

Capacity is memory only while data is queued (tokio's bounded channel does not preallocate), so the cost is bounded to 32 chunks during a downstream stall. Two filesystem-store tests that depended on the 2-slot capacity stream a longer value instead.

AI assistance

Written with Claude Code; b7r6 reviewed the change. Draft until the author has read the CI results.

🤖 Generated with Claude Code