fix: deliver the rest of the invalid_request class to the client - #28736

Stacked on #28450. Review that first; this PR's diff is only the top four commits.

TL;DR

#28450 moved three authorization failures to the client's callback per RFC 6749 §4.1.2.1 and left the largest group behind. A malformed code_challenge, a malformed resource, an unparseable response_type, or an excess parameter still stopped on Coder with no state, so the app never learned its request failed and waited on an authorization that would never arrive. Same defect #28450 exists to fix, on the path #28450 did not touch.

Contract change. These now redirect to the registered callback with error=invalid_request, a description naming the failing fields, and the request's state, on both verbs:

Two failures still answer on Coder, because in both cases the callback is not trustworthy yet: a redirect_uri that does not parse or does not match the registration, and a missing or unparsable client_id.

Precedence change. An app whose registered callback has a rejected scheme now answers 500 even when the request also carries parser errors; that combination used to answer 400. Only reachable for an app row that bypassed registration. No test pinned the old precedence; DangerousCallbackSchemeOutranksParseFailure pins the new one.

Both preconditions move into a constructor (2ec3bdb)

Writing a Location from inside the parser's error branch would run before the scheme check, which is the hazard DangerousCallbackSchemeNotRedirected guards. validatedCallbackURL becomes authorizeResponse, built only by newAuthorizeResponse, which runs the scheme check and the exact match against the registration in that order. Holding one is what licenses a redirect, so the ordering is structural rather than a convention each call site has to remember.

• The scheme check runs on the registered URL, not on the parser's result: p.RedirectURL returns the client's URI on a mismatch, so checking that would answer 500 and log the app as corrupt for a request the app never made. DangerousClientSchemeIsNotTheServersFault pins it.
• A mismatch zeroes the callback, so canRedirect() is false for any redirect_uri failure. The type refuses to name a destination it could not validate.
• state moves onto the type, out of the parameter lists of withQuery, errorURL, codeURL, and redirectAuthorizeError, so no call site can emit a response the client cannot correlate.

Classification replaces implicit ordering (90be3d1)

extractAuthorizeParams returns one authorizeFailure instead of two trailing values, giving both handlers the same three-way decision: bad server state answers 500, a deliverable failure redirects, everything else stays on Coder.

blamesClient tests only client_id, since the redirect-URI carve-out is already structural. That carve-out is reachable in practice, not just defensively: httpmw accepts the RFC 6749 §2.3.1 Basic credential as client_id, so the query parameter can legitimately be empty.

API reference (a68a32d)

Both authorize endpoints reject response_type=token, but the reference listed it as an accepted value. CRF-15 on #28450 asked for this alongside the 302 rows and it was the one part left undone. Enums on the typed parameter appends to the list swaggo derives from the type rather than replacing it, so narrowing it means declaring the parameter as a string. codersdk.OAuth2ProviderResponseType keeps both constants, since it also feeds ResponseTypesSupported.

Left alone on purpose. CRF-26 (the server_error sites) and CRF-13 (fragment delivery), both as in #28450.

Refs PLAT-479.