Accept and Store `verified_claims` in the Authorize `claims` Parameter

[sacrana0]

Summary

Accept the OIDC Identity Assurance (IDA) verified_claims member in the userinfo
section of the authorize claims parameter, store it in the authorization request
store, and ignore it everywhere else.

ClaimsRequest.UserInfo (currently map[string]*IndividualClaimRequest) cannot hold a
verified_claims value, whose request form is the nested IDA structure
(verification + claims), not the {essential, value, values} shape. Widening
UserInfo to map[string]any lets it carry both normal claims and verified_claims.

This is accept-and-store only: Thunder never resolves, verifies, or returns
verified_claims.

Goals

• Change ClaimsRequest.UserInfo to map[string]any.
• Validate userinfo.verified_claims against the IDA request structure; keep existing
  OIDC validation for normal claims.
• Persist verified_claims in auth_req_store (DB JSONB + cache) and reconstruct it
  faithfully on retrieval.
• Keep all other consumers (essential/optional classification, claim filtering,
  sub-claim constraint, UserInfo/token building) operating only on normal claims.

Non-goals

• No verified_claims in the id_token section; ClaimsRequest.IDToken is unchanged.
• No resolution, verification, or return of verified_claims in any output.
• No new data model, schema change, or client config for verified data
  (verified_claims rides inside the existing REQUEST_DATA JSONB).

Acceptance criteria

1. ClaimsRequest.UserInfo is map[string]any; IDToken unchanged; existing tests
   pass after consumers are adapted.
2. A claims parameter with userinfo.verified_claims is accepted and the value is
   retained in the parsed ClaimsRequest.
3. Full IDA validation: malformed verified_claims (missing verification /
   trust_framework / claims) is rejected with invalid_request; both object and
   array-of-objects forms are accepted when valid. Normal-claim validation is unchanged.
4. Round-trip: after persist + reload (DB and cache), the reconstructed verified_claims
   equals the submitted one.
5. verified_claims never appears in required-attribute sets, BuildClaims output, the
   UserInfo response, ID token, access token, or sub-claim constraint checks. Responses
   for normal claims are identical with or without verified_claims present.
6. Unit tests cover parsing, IDA validation (valid/invalid/array), the store round-trip,
   and the "ignored everywhere else" guarantees.

Known edge cases / risks / dependencies

• Normalization: with UserInfo as map[string]any, every non-verified_claims
  entry must be re-decoded into *IndividualClaimRequest wherever the old code iterated
  typed values. A null value ("email": null) still means "requested, no constraint".
  Centralize the verified_claims exclusion in one helper to keep the no-leakage
  guarantee robust.
• Shape variants: accept single-object and array-of-objects verified_claims;
  aggregated/distributed forms are out of scope (stored opaquely).
• Round-trip fidelity: parseClaimsRequestFromJSON must avoid lossy coercion (e.g.
  numeric handling) so the reloaded value matches the original.
• Wider consumer surface: the type change touches every reader of UserInfo; a
  missed site either fails to compile or mis-handles normal claims — covered by tests.
• Dependency: OIDC IDA spec for the verified_claims request structure; existing
  auth_req_store and claims parse/validate utilities
  (oauthutils.go, model/parameter.go).