fix: bound request body size on JSON API endpoints (#28168)

## Summary

`httpapi.Read` decoded request bodies with no size limit, so a single
request could allocate memory without bound. This adds a 4 MiB default
ceiling, leaves the endpoints that legitimately need more explicitly
exempted, and counts the rejections so a limit set too tight is visible.

This is the first of three PRs split out of #28048, covering the
endpoints that answer in `codersdk.Response` shape. The OAuth2 decode
paths (RFC 6749, RFC 7591) and the SCIM ones (RFC 7644) answer in their
own error shapes and follow in separate PRs, along with the lint rule
that pins the invariant.

Closes PLAT-463. Remediates SEC-416 (CWE-770, CVSS 7.5) and SEC-392.

## Problem

`httpapi.Read` calls `json.NewDecoder(r.Body).Decode(value)` with no
ceiling, and no middleware in the chain bounds body size. The exposure
is pre-authentication: login, OTP, and first-user creation all read a
body before any authorization decision is reached. The existing rate
limiter bounds request *rate*, which is orthogonal to the memory a
single admitted request may consume.

## Fix

`Read` is split into `Read` and `ReadLimit`. `ReadLimit` wraps `r.Body`
in an `http.MaxBytesReader` and keeps the existing decode and validate
logic; `Read` delegates to it with a new `DefaultMaxRequestBodyBytes` of
4 MiB, which covers the 124 remaining non-test callers at a single site.

`http.MaxBytesReader` composes as tightest-wins, so the handlers that
pre-wrapped their own bodies pass their limit to `ReadLimit` rather than
wrapping, and each keeps its previous ceiling byte for byte. That
matters most for the bulk secrets import at `8 * MaxSecretsFileBytes`:
an unconditional wrap inside `Read` would have silently halved it to the
default. `TestImportUserSecretsBodyLargerThanDefaultLimit` is the
regression guard for that specific failure, and
`TestMaxBytesReaderNesting` pins the composition behavior the whole
requirement rests on.

Every rejection site calls `httpapi.RecordRequestBodyLimit`, which names
the limit that tripped on the request's existing log line and marks the
request so `coderd_api_requests_too_large_total{reason="request_body"}`
counts body rejections apart from the 413s coderd answers for other
causes, such as agent log storage overflow. A limit set too tight for a
legitimate payload therefore surfaces without waiting for a user report.

The limit is a constant rather than a deployment option: an operator
raising it to unblock something would reopen the vulnerability as
configuration, where a security scan will not find it. A legitimate 413
is answered with a targeted `ReadLimit` on that endpoint.

## Behavior change

`POST /api/v2/files` now answers 413 rather than 400 when a request body
exceeds `HTTPFileMaxBytes`. It installed that bound already but reported
the rejection as a read failure, which leaked the stdlib `http: request
body too large` string through `Detail` and kept the largest limit in
the tree off the metric. The separate 413 for an oversized expanded
archive is unchanged.

The task log snapshot endpoint now answers 413 rather than 400 when its
64 KiB cap is exceeded. Routing it through `ReadLimit` also changes its
decode-failure message from "Failed to decode request payload." to
"Request body must be valid JSON.", which is what every other endpoint
answers. Its tests are updated to match both.

`coderd_api_requests_too_large_total` is new, so there is no existing
query to migrate. It counts the 413s coderd answers, labeled `method`,
`path`, and `reason`. `reason="request_body"` is a rejection by one of
the limits above; `reason="other"` is a 413 that has nothing to do with
body size, such as agent log storage overflow.

## Reading this

The commits are ordered to be read in sequence. Commits 1 and 2 are the
security fix; commits 3 to 5 are the observability consequences, and
commit 3 is the one that touches dashboards. Commit 7 documents the
limit on the REST API reference index. Commits 6 and 8 add and revert an
exhaustive `@Failure 413` annotation pass, which buried the fix under
its regenerated swagger, and cancel out.

coderd/httpapi/httpapi.go

@@ -229,20 +229,47 @@ func WriteIndent(ctx context.Context, rw http.ResponseWriter, status int, respon
 	_ = enc.Encode(response)
 }
 
-// Read decodes JSON from the HTTP request into the value provided. It uses
-// go-validator to validate the incoming request body. ctx is used for tracing
-// and can be nil. Although tracing this function isn't likely too helpful, it
-// was done to be consistent with Write.
+// DefaultMaxRequestBodyBytes bounds the request body that a JSON endpoint will
+// decode. It exists so that a single request, including an unauthenticated one,
+// cannot exhaust server memory with an oversized body. Endpoints that need a
+// different limit must call ReadLimit rather than change this constant.
+const DefaultMaxRequestBodyBytes = 4 << 20 // 4 MiB
+
+// Read decodes JSON from the HTTP request into the value provided, reading at
+// most DefaultMaxRequestBodyBytes from the body. It uses go-validator to
+// validate the incoming request body. ctx is used for tracing and can be nil.
+// Although tracing this function isn't likely too helpful, it was done to be
+// consistent with Write.
 func Read(ctx context.Context, rw http.ResponseWriter, r *http.Request, value interface{}) bool {
+	return ReadLimit(ctx, rw, r, DefaultMaxRequestBodyBytes, value)
+}
+
+// ReadLimit is Read with an explicit request body size limit, for endpoints
+// that need one above or below DefaultMaxRequestBodyBytes. Most callers set a
+// tighter one.
+//
+// Callers must use this rather than wrapping r.Body in an http.MaxBytesReader
+// themselves. Read installs its own limit, and nested readers compose as
+// tightest-wins, so the default would override a larger caller-supplied limit.
+func ReadLimit(ctx context.Context, rw http.ResponseWriter, r *http.Request, limit int64, value interface{}) bool {
 	ctx, span := tracing.StartSpan(ctx)
 	defer span.End()
 
+	r.Body = http.MaxBytesReader(rw, r.Body, limit)
+
 	err := json.NewDecoder(r.Body).Decode(value)
 	if err != nil {
-		if _, ok := errors.AsType[*http.MaxBytesError](err); ok {
+		// Report the limit the error carries, not the one this call installed.
+		// Nested readers compose as tightest-wins and the error carries the
+		// winner, so a caller that wrapped r.Body tighter would otherwise be
+		// told a limit far looser than the one that rejected it.
+		if mbe, ok := errors.AsType[*http.MaxBytesError](err); ok {
+			// Must be r.Context(), not ctx: ctx is the caller's and need not
+			// be the request's, but the tracker rides the request's.
+			RecordRequestBodyLimit(r.Context(), mbe.Limit)
 			Write(ctx, rw, http.StatusRequestEntityTooLarge, codersdk.Response{
 				Message: "Request body too large.",
-				Detail:  err.Error(),
+				Detail:  fmt.Sprintf("Maximum request body size is %d bytes.", mbe.Limit),
 			})
 			return false
 		}