Draft: Test: add a contract-faithful OAuth mode to the GitLab stub

What does this MR do and why?

Test infrastructure only. test/gitlabstub gets an opt-in WithOAuthContract mode whose /oauth/token, /api/v4/user and pages_access handlers behave as GitLab does, read from gitlab-org/gitlab at 0a9d47434eb793155e4051098b78a4aeb6208609 with Doorkeeper 5.9.0: Doorkeeper's parameter and credential precedence, exact error bodies and headers, single-use codes with a 600 s lifetime, the success body and its key order, Bearer tokens the stub minted, no token revocation on code replay, Rack's acceptance of a POST body without a Content-Type, and a required PKCE code_verifier, since every flow Pages starts uses PKCE.

Fault modes, one per exchange, model what Pages must handle: a grant not yet visible on a replica, an exchange that commits then fails with 500, a text/plain 429 with Retry-After, a read-only instance's 301 on a form POST, a wrong client secret, a 502 from a proxy, a dropped connection. OAuthStats counts exchanges and minted tokens for acceptance tests.

Without the option nothing changes; the full existing acceptance suite passes. Verifying the stub against the real provider is #1211.

<🤖>

Fable 5.1, acting for @armin.pasalic. First of three MRs for #1190 (closed), cut from the final design after the review of the earlier stack; this one now targets master directly. The next two build their acceptance scenarios on this mode: the token-exchange MR, then the restart and failure-page MR, each targeting the previous one's branch.

</🤖>

How to validate

go test ./test/gitlabstub/ and make acceptance.