docs: Point streaming cap references at the new setting

Javadoc and README now name maxDecompressedStreamingRequestBytes where
streamed bodies are concerned. Adds an IT holding a streaming extra
route to the streaming cap, with the setters in reverse order.

Author: thced

README.md

@@ -499,7 +499,7 @@ OpenApiServer.builder()
 Note this bounds the *inflated* size of a coded body, whatever the coding. It is not a request size
 limit — a body that arrives uncompressed is read in full, as it always has been. For a
 [streaming handler](#streaming-request-bodies), the cap is enforced as the handler reads, and
-[can be set separately](#raising-the-cap-for-streamed-bodies), past 2 GiB.
+[can be set separately](#a-separate-cap-for-streamed-bodies), past 2 GiB.
 
 **Responses.** A body is gzipped when the client sends `Accept-Encoding: gzip`, the media type is
 text-shaped (`text/*`, `application/json`, `application/xml`, `application/yaml`, and the `+json` /
@@ -542,7 +542,8 @@ OpenApiServer.builder()
 
 The client's weights pick the coding; on a tie, registered codings win over gzip, in registration
 order. `decode` and `encode` wrap streams rather than whole bodies, so a decoder that reads lazily
-is held to `maxDecompressedRequestBytes` without doing anything itself. `requestContentCoding` and
+is held to `maxDecompressedRequestBytes` (or, for a streaming handler,
+`maxDecompressedStreamingRequestBytes`) without doing anything itself. `requestContentCoding` and
 `responseContentCoding` register one direction only; a request coded with a response-only coding
 gets 415. Tokens must be lower-case, and `gzip`, `x-gzip`, `identity` and `*` are reserved.
 
@@ -1036,7 +1037,7 @@ What changes:
   is closed rather than reused.
 - **A `Content-Encoding` is decoded as the handler reads**, capped by
   [`maxDecompressedRequestBytes`](#content-encoding) unless a
-  [streaming cap](#raising-the-cap-for-streamed-bodies) is set. Going over the cap, or a body that
+  [streaming cap](#a-separate-cap-for-streamed-bodies) is set. Going over the cap, or a body that
   fails to decode, surfaces from `read` as a `BadRequestException` (413 or 400). The client
   dropping the connection surfaces as the plain `IOException` it would be for an uncoded body.
   Let it propagate and the `ExceptionHandler` renders it as usual. By then the handler may
@@ -1054,16 +1055,19 @@ Tests can build a streaming request directly with `Request.streaming(InputStream
 buffered requests, `bodyStream()` returns a fresh stream over `bytes()`, so a helper that reads a
 stream works for both.
 
-### Raising the cap for streamed bodies
+### A separate cap for streamed bodies
 
 `maxDecompressedRequestBytes` bounds buffered bodies too, which are held in a `byte[]`, so it
 can't go above 2 GiB. A streamed body is never held in memory, so it can have a cap of its own,
-any positive `long`:
+any positive `long` — higher than the buffered one, or lower:
 
 ```java
 OpenApiServer.builder()
+    .spec(spec)
+    .handlers(handlers)
     .maxDecompressedRequestBytes(32 * 1024 * 1024)                  // buffered: 32 MiB
     .maxDecompressedStreamingRequestBytes(50L * 1024 * 1024 * 1024) // streamed: 50 GiB
+    .build();
 ```
 
 Left unset, streamed bodies share `maxDecompressedRequestBytes`. It covers decoded bodies only;

docs/superpowers/plans/2026-10-08-streaming-request-bodies.md

@@ -194,5 +194,6 @@ Spec: "Streaming decompression cap". Lifts the 2 GiB ceiling on decoded streams
 - [x] **Step 1:** `RequestBodyReader`: three-argument constructor `(maxDecompressedBytes, maxStreamedDecompressedBytes, decoders)`, both validated positive; the two-argument constructor delegates with the same cap. `stream` passes the streamed cap to `DecodingInputStream`; `read` is unchanged.
 - [x] **Step 2:** `Builder.maxDecompressedStreamingRequestBytes(long)` — any positive `long`; unset falls back to `maxDecompressedRequestBytes` at `build()`. Javadoc on both setters.
 - [x] **Step 3:** Tests. Unit: streamed body held to its own cap, buffered body keeps its cap when the streamed one is higher, constructor rejects a non-positive streamed cap; builder accepts `Integer.MAX_VALUE + 1` and `Long.MAX_VALUE`, rejects 0 and -1. IT: a gzip body past the buffered cap streams when the streaming cap is higher; one past the streaming cap is 413.
-- [x] **Step 4:** README "Raising the cap for streamed bodies", cross-links from "Content encoding", the streaming bullets and "Raw bodies"; spec section and constraint; this task.
+- [x] **Step 4:** README "A separate cap for streamed bodies", cross-links from "Content encoding", the streaming bullets and "Raw bodies"; spec section and constraint; this task.
 - [x] **Step 5:** `pre-commit run`, `mvn verify`, SonarLint on changed files; commit `feat: Separate decompression cap for streamed bodies` (signed) and push to PR #131.
+- [x] **Step 6: Review (Opus, SHIP WITH FIXES, docs only).** Point the `StreamingRequestHandler`, `ContentCoding` and `contentCoding` javadoc and the README coding paragraph at the streaming cap; rename the README section to "A separate cap for streamed bodies" (it can be lower too) and complete its snippet; rewrap the spec paragraph. IT: a streaming extra route is held to the streaming cap, with the setters in reverse order.

docs/superpowers/specs/2026-10-08-streaming-request-bodies-design.md

@@ -65,11 +65,11 @@ Buffered operations keep their exact order (body read, then 404/405, then valida
 A coded body is decoded lazily by `DecodingInputStream`, which opens the decoder once the first
 byte arrives (so an empty coded body reads as empty, as when buffered) and counts decoded bytes
 against the streaming cap (`maxDecompressedStreamingRequestBytes`, defaulting to
-`maxDecompressedRequestBytes`; see "Streaming decompression cap"). Exceeding the cap throws `BadRequestException(413)` from
-`read`; a decoder failure throws `BadRequestException(400)`. Both propagate out of the handler to
-the `ExceptionHandler`. The header view hides `Content-Encoding` and `Content-Length` for a decoded
-body, since the decoded length is unknown up front. Identity bodies are passed through uncapped,
-matching the buffered path.
+`maxDecompressedRequestBytes`; see "Streaming decompression cap"). Exceeding the cap throws
+`BadRequestException(413)` from `read`; a decoder failure throws `BadRequestException(400)`. Both
+propagate out of the handler to the `ExceptionHandler`. The header view hides `Content-Encoding`
+and `Content-Length` for a decoded body, since the decoded length is unknown up front. Identity
+bodies are passed through uncapped, matching the buffered path.
 
 ### Boot validation
 

src/main/java/com/retailsvc/http/ContentCoding.java

@@ -17,9 +17,10 @@
  *
  * <p>Both methods wrap a stream rather than convert a whole body: return a stream that codes as it
  * is read or written. For {@link #decode} this is what bounds the work — the server reads at most
- * {@code maxDecompressedRequestBytes} from the stream you return, so a lazy decoder is protected
- * from decompression bombs without doing anything, while one that expands the whole body up front
- * has already spent what that limit exists to protect.
+ * {@code maxDecompressedRequestBytes} (or {@code maxDecompressedStreamingRequestBytes} for a
+ * streaming handler) from the stream you return, so a lazy decoder is protected from decompression
+ * bombs without doing anything, while one that expands the whole body up front has already spent
+ * what that limit exists to protect.
  */
 public interface ContentCoding {
 

src/main/java/com/retailsvc/http/OpenApiServer.java

@@ -462,7 +462,8 @@ public Builder minCompressibleResponseBytes(long minCompressibleResponseBytes) {
      * Registers a content coding the server decodes on requests and applies to responses, alongside
      * the built-in gzip. When a client weights several codings equally, the ones registered here
      * win over gzip, in registration order; otherwise the client's weights decide. A decoded body
-     * is still held to {@link #maxDecompressedRequestBytes(long)}.
+     * is still held to {@link #maxDecompressedRequestBytes(long)}, or to {@link
+     * #maxDecompressedStreamingRequestBytes(long)} for a streaming handler.
      *
      * @throws IllegalArgumentException if a token or alias is not a lower-case RFC 9110 token, or
      *     is one of the reserved {@code gzip}, {@code x-gzip}, {@code identity} or {@code *}

src/main/java/com/retailsvc/http/StreamingRequestHandler.java

@@ -25,9 +25,10 @@
  * through {@link Request#bodyStream()}, once, before {@link #handle(Request)} returns.
  *
  * <p>A registered {@code Content-Encoding} is decoded as the handler reads, and the decoded size is
- * held to {@link OpenApiServer.Builder#maxDecompressedRequestBytes(long)}. A body that exceeds it,
- * or fails to decode, surfaces from the stream's {@code read} as a {@link BadRequestException} (413
- * or 400) — possibly after the handler has already passed earlier bytes on. An uncoded body has no
+ * held to {@link OpenApiServer.Builder#maxDecompressedStreamingRequestBytes(long)}, which defaults
+ * to {@link OpenApiServer.Builder#maxDecompressedRequestBytes(long)}. A body that exceeds it, or
+ * fails to decode, surfaces from the stream's {@code read} as a {@link BadRequestException} (413 or
+ * 400) — possibly after the handler has already passed earlier bytes on. An uncoded body has no
  * size limit. To receive a coded body exactly as sent instead, see {@link #raw}.
  *
  * <p>Concurrent streaming requests can be capped server-wide with {@link

src/test/java/com/retailsvc/http/StreamingRequestBodyIT.java

@@ -298,6 +298,26 @@ void extraRouteStreamsItsBody() throws Exception {
     assertThat(response.headers().firstValue(RECEIVED)).hasValue("2048");
   }
 
+  @Test
+  void streamingExtraRouteIsHeldToTheStreamingCapWhicheverSetterComesFirst() throws Exception {
+    start(
+        Map.of(),
+        b ->
+            b.extraRoute("/ingest", counting())
+                .maxDecompressedStreamingRequestBytes(1024)
+                .maxDecompressedRequestBytes(1024 * 1024));
+    URI ingest = URI.create("http://localhost:%d/ingest".formatted(server.listenPort()));
+
+    var response =
+        send(
+            HttpRequest.newBuilder()
+                .uri(ingest)
+                .header("Content-Encoding", "gzip")
+                .POST(BodyPublishers.ofByteArray(gzip(new byte[64 * 1024]))));
+
+    assertThat(response.statusCode()).isEqualTo(HTTP_ENTITY_TOO_LARGE);
+  }
+
   @Test
   void streamingHandlerOnAnOperationWithoutARequestBodyFailsAtBoot() {
     OpenApiServer.Builder builder =