fix: bound OAuth2 request bodies and report the rejection per RFC - #28175

Summary

Bounds the two OAuth2 paths from r.Body to a decoded value that do not go through httpapi.Read, and reports each rejection in the error shape its caller expects rather than the codersdk.Response that httpapi.Read writes.

Second of three PRs split out of #28048. Stacked on #28168, which adds the httpapi.ReadLimit primitive and RecordRequestBodyLimit that this PR builds on. Review that one first; the diff shown here is against its branch. The SCIM remediation and the lint rule follow in a third PR.

Refs PLAT-463. Part of the remediation for SEC-416 (CWE-770, CVSS 7.5).

Problem

httpapi.Read is not the only path from a request body to a decoded value.

POST /oauth2/tokens and POST /oauth2/revoke authenticate the client from the request body, so they carry no API key middleware and r.ParseForm ran before any authorization decision. These were not unbounded, since net/http caps an unwrapped urlencoded body at its own 10 MiB maxFormSize, but that is an asymmetric pre-auth ceiling 2.5x the one every other endpoint carries, on a prefix mounted outside apiRateLimiter.

POST /oauth2/register is also reachable pre-authentication. It decoded through httpapi.Read, which reports a codersdk.Response, making it the one protocol-inconsistent response in a handler that is otherwise RFC 7591 compliant. That inconsistency becomes visible once httpapi.Read starts answering 413.

Fix

The form endpoints get a MaxBytesReader at DefaultMaxRequestBodyBytes installed in extractOAuth2ProviderAppBase, ahead of every reader; net/http defers to one when it finds it, so this replaces maxFormSize. tokens.go and revoke.go translate the same error, because the middleware parses the form only when client_id is absent from the query string, and when it is present those handlers perform the first read.

/oauth2/register bounds and decodes locally in readOAuth2ClientRegistrationRequest. http.MaxBytesReader surfaces the limit through the decoder's error, so the error shape belongs to whoever decodes; that is why the decode moves into the handler rather than passing a limit to httpapi.ReadLimit. The limit itself is unchanged from what httpapi.Read applied.

RFC 6749 defines no error code for a transport rejection, and RFC 7591 section 3.2.2 defines invalid_client_metadata and friends for semantic validation rather than transport rejection, so invalid_request is the closest compliant framing in both.

Two fixes here that are not about body size

Called out separately so they are not skimmed past while checking the size bounds. Each is its own commit.

The middleware discarded its ParseForm error, so an oversized body reported the client_id it may well have carried as missing. A size failure is now reported as one; any other parse failure still falls through, since the client_id may arrive through HTTP Basic.

The registration 400 carried a fixed sentence, so an integrator saw one message whether a proxy had returned HTML or redirect_uris carried a string where an array belongs. It now carries the decoder's own text, which names the offending field and the expected type, describes the caller's own bytes so it discloses nothing, and is what httpapi.Read has exposed on every other endpoint for as long as it has existed. TestOAuth2SpecificErrorScenarios/InvalidJSONStructure was an empty subtest claiming coverage happened implicitly through typed request structs, which by construction cannot produce a decode failure; it now posts raw bodies and asserts the shape.

Behavior change

POST /oauth2/tokens and POST /oauth2/revoke now answer 413 with an RFC 6749 invalid_request once a form body passes 4 MiB. Previously such a body ran to net/http's 10 MiB cap and was reported as a 400 naming client_id as missing.

POST /oauth2/register now answers 413 as an RFC 7591 error rather than a codersdk.Response. Its 400 for a malformed body now carries the JSON decoder's text in error_description; the status and the RFC 7591 error code are unchanged.