docs(tasks): decompose review-002 into 24 tasks (23 implementation + 1 bracketed follow-up)

Decomposition of docs/reviews/002-post-remediation-review.md per its
5-unit remediation plan:

- Unit 1 (security-critical): gw15-publish-body-cap,
  prj16-schema-via-call (CF-004 filed alkcall-side), fwd13-dot-segments,
  fwd16-missing-capability, oai11-ref-memoization
- Unit 2 (timeout/terminality): ws13-idle-progress,
  fwd15-stream-timeout, cli01-retry-after-budget, con17-mcp-pagination,
  con18-wss-sweep-exit
- Unit 3 (projection/docs): projection-truthfulness, mcp-batch-cap,
  gw16-status-drift
- Unit 4 (spec-import): yaml-normalization, oai13-path-item-wildcards,
  import-loudness-cluster, js01-placeholder-check,
  fwd17-19-contract-decisions
- Unit 5 (WS polish + tests): con18b-ws-polish,
  client-policy-wire-tests, cov-deployment-knobs, cov13-dead-code,
  srv11-srv12-router-ordering
- review-002-bracketed-followup: tentatively planned post-bulk pass
  (stale-check, OQA-18 enforcement decision, CON-08/09 close() lever,
  cross-crate re-checks) — deliberately not serialized against the
  bulk

Also: review-002 numbering repair (CON-14 was double-booked; MCP
pagination now CON-14, from_wss monitor renumbered CON-18, missing
CON-14 section added).

taskgraph: 66 valid, no cycles; 24 pending (all review-002);
gen-1/gen-2 parallel waves identified; workflow-cost hotspots are
prj16 (12.8) and ws13 (11.1), both carrying the reviewed slicing
guidance in their Notes.

tasks/gateway/review-002-gw15-publish-body-cap.md

@@ -0,0 +1,77 @@
+---
+id: review-002-gw15-publish-body-cap
+name: Cap /publish body buffering pre-newline + explicit body-limit layer (GW-15)
+status: pending
+depends_on: []
+scope: moderate
+risk: medium
+impact: component
+level: implementation
+tags: [gateway, review-002, security]
+---
+
+## Description
+
+Review 002 GW-15 [major] — `/publish` lost both claimed memory bounds
+in the GW-06 streaming rewrite. Verified at tree `91483a7`:
+
+1. **No body limit on the route.** `publish_handler` takes raw
+   `axum::body::Body` (`src/gateway/routes.rs:249-253`). axum's
+   2 MiB `DefaultBodyLimit` is a request *extension* consulted only by
+   extractors (axum-core `request_parts.rs` returns the raw body
+   untouched) — a raw-Body handler has **no** default limit. The
+   module doc's claim ("in addition to axum's own 2 MiB default body
+   limit") is false on this route.
+2. **Unbounded line buffer.** `BufferedLines::next_line`
+   (`routes.rs:425-448`) enforces `MAX_PUBLISH_LINE_BYTES` only when a
+   `\n` is found; bytes accumulate in `self.buffer` unboundedly until
+   then, and the trailing-EOF `std::mem::take(&mut self.buffer)` path
+   has no cap check at all.
+
+Concrete failure: unauthenticated `POST /publish` with chunked
+transfer-encoding streaming `'a'` forever (no newline) → heap grows
+with the upload until OOM; each poll also re-scans the whole buffer
+from index 0 → O(n²) CPU on top. This is the SRV-03 class one route
+over (SRV-03 fixed `/mcp`; `/publish` regressed into the same class
+via the streaming rewrite).
+
+## Acceptance Criteria
+
+- [ ] `BufferedLines` errors (terminal `LineError::LineCap` → the same
+      INVALID_INPUT family the line-cap error uses today) once
+      `self.buffer.len() > MAX_PUBLISH_LINE_BYTES`, checked *before*
+      extending, even with no newline seen — the trailing-EOF
+      `mem::take` path cannot exceed the cap
+- [ ] The publish route (or the whole gateway router) carries an
+      explicit request-body-limit layer so it does not depend on
+      extractor-side defaults for raw-Body handlers (size = the 2 MiB
+      convention; note in module doc)
+- [ ] Wire test: chunked upload with no `"\n"` for > cap bytes is
+      rejected with the documented status/body (not 200, not OOM)
+- [ ] Wire test: EOF without newline after > cap buffered bytes also
+      rejected (the `mem::take` path)
+- [ ] Existing publish tests still pass (first-line handling, NDJSON
+      streaming, schema validation, caps on terminated lines)
+- [ ] `cargo test`, `cargo clippy --all-targets -- -D warnings`,
+      `cargo fmt --check` pass
+
+## References
+
+- docs/reviews/002-post-remediation-review.md (Part C', GW-15; Part G', COV-12 `BufferedLines` hot spot)
+- docs/architecture/decisions/068-gateway-publish-endpoint.md
+- src/gateway/routes.rs:249-253 (handler), 395-470 (BufferedLines)
+- tasks/gateway/review-001-publish-schema-validation-robust.md (the cache this must not stale)
+
+## Notes
+
+The line-cap test that exists today (`publish_line_exceeding_cap…`)
+short-circuits at the route level in single-chunk delivery — the new
+pre-extend check must be exercised with a **streamed** (multi-chunk,
+never-newline) body, which is the shape the old test cannot see. Keep
+`MAX_PUBLISH_LINE_BYTES` as the single cap constant; a separate total
+cap is optional (the layer limit bounds the total once landed).
+
+GW-16 (the 400-vs-422 drift on the cap error's status) is deliberately
+NOT in scope here — see review-002-gw16-status-drift; land the cap with
+today's status first, then normalize statuses in that task to avoid
+churn in the same lines.