OIDC Core 1.0 §3.3 defines the hybrid flow with three response_type
combinations that were previously rejected: 'code id_token',
'code token', and 'code id_token token'. This commit also adds the
pure-implicit 'id_token token' combination for completeness.

Changes to /authorize handler:

- New supportedResponseTypeSet helper parses response_type as a
  space-delimited set, lowercases, dedupes, and sorts the tokens.
  Returns a canonical string and a validity bool. Order is now
  insignificant: 'token id_token code' → 'code id_token token'.
- Unsupported combinations return OIDC error
  unsupported_response_type (HTTP 400).
- Hybrid-specific guard: response_mode=query is rejected with
  invalid_request per OIDC Core §3.3.2.5. When the client did not
  supply a response_mode for a hybrid request, the default is
  fragment (not query, regardless of server's global default).
- New hybrid dispatch branch that mints tokens AND a code in a
  single response. Sets cfg.Code on the AuthTokenConfig, which was
  already wired in Phase 1 to populate cfg.CodeHash and emit the
  c_hash claim on the ID token.
- Response artifacts are assembled conditionally based on the
  requested combination: code is always present; access_token is
  present iff the combo includes 'token'; id_token is present iff
  the combo includes 'id_token'.

What's already done (no change needed):

- Phase 1's CreateIDToken already emits c_hash whenever cfg.CodeHash
  is populated. The hybrid branch just needs to set cfg.Code before
  calling CreateAuthToken — the hash computation and claim emission
  are already plumbed.

New test file oidc_phase3_hybrid_test.go:

- Unsupported response_type rejected
- response_mode=query rejected for hybrid
- All four new combinations accepted by the parser
- Token order in response_type is insignificant

Backward compatibility: single-value 'code', 'token', 'id_token'
response_types still work identically. No client behavior change
for non-hybrid flows.

Allow operators to configure a SECONDARY JWT key alongside the
primary. When configured, the JWKS endpoint publishes both public
keys with distinct kids so relying parties can verify tokens signed
by either. Enables zero-downtime key rotation.

New config fields (all default empty, opt-in):

- JWTSecondaryType (algorithm — e.g. RS256)
- JWTSecondarySecret (HMAC secret — never exposed via JWKS)
- JWTSecondaryPrivateKey
- JWTSecondaryPublicKey

New CLI flags mirroring existing --jwt-* pattern:

- --jwt-secondary-type
- --jwt-secondary-secret
- --jwt-secondary-private-key
- --jwt-secondary-public-key

JWKS handler changes (internal/http_handlers/jwks.go):

- Refactored into a pure generateJWKFromKey(algo, pub, kidSuffix,
  clientID) helper used for both primary and secondary.
- Primary kid stays unchanged ('-' + clientID suffix dropped for
  backward compat).
- Secondary kid appends '-secondary' so primary and secondary are
  always distinguishable even when they use the same algorithm.
- HMAC secondaries are silently dropped (never exposed), consistent
  with primary HMAC behavior.
- Errors on secondary key generation are logged and the secondary
  is dropped — a malformed secondary config never breaks the JWKS
  endpoint (primary keeps working).

Documented manual rotation workflow (commit message):

1. Operator adds new key as --jwt-secondary-*
2. Server publishes both keys in JWKS; both can verify new tokens
3. Operator swaps: new key becomes primary (--jwt-*), old becomes
   secondary (--jwt-secondary-*)
4. Wait for outstanding tokens to expire (default 30 days for
   refresh tokens)
5. Operator removes --jwt-secondary-* flags

Deliberately out of scope for this commit: token signature
verification fallback. The current verifier in internal/token only
tries the primary key; after step 3 above, outstanding tokens
signed with the now-secondary key would fail verification. This
gap will be addressed in a follow-up commit that adds a retry path
to ParseJWTToken. Documented as a known limitation in the
post-phase review.

No automation of key rotation in this commit — automated
time-based rotation is a Phase 4 roadmap item.

Backward compatibility: when no secondary is configured, behavior
is byte-identical to the existing single-key path.

New test file oidc_phase3_jwks_multi_key_test.go:

- Default (no secondary) publishes exactly one key
- Both keys published with distinct kids when secondary configured
- HMAC secondary is not exposed

Implements OIDC Back-Channel Logout 1.0. On successful /logout,
when the operator has configured --backchannel-logout-uri, fire a
signed logout_token JWT via HTTP POST to that URI. Fire-and-forget
from a goroutine so logout UX is never blocked by the receiver.

New config field (opt-in, default empty):

- BackchannelLogoutURI string

New CLI flag:

- --backchannel-logout-uri

New file: internal/token/backchannel_logout.go

- BackchannelLogoutConfig struct carrying HostName, Subject, SessionID
- NotifyBackchannelLogout() method on the token Provider. Added to
  the token.Provider interface so callers can mock it. Method builds
  a logout_token JWT per OIDC BCL 1.0 §2.4 with:
    iss, aud, iat, exp (+5 min), jti (uuid), events map containing
    the BCL event identifier, and sub + sid when available.
  Deliberately omits nonce — prohibited by spec §2.4.
- Signs via existing SignJWTToken, POSTs as x-www-form-urlencoded
  with 5-second HTTP timeout (context + client). Receiver response
  is not inspected — logout completes regardless.

/logout handler change:

- After successful session termination + audit log, if
  BackchannelLogoutURI is set, launch a goroutine that calls
  NotifyBackchannelLogout with sessionData.Subject as sub and
  sessionData.Nonce as sid. Errors logged at debug.

The receiver verifies the logout_token signature using the same
JWKS endpoint as ID token verification. No new secrets, no new
keys, no new endpoints to secure.

Intentional design choices:

- logout_token is signed with the SAME key as ID tokens so the RP
  already has everything it needs to verify it (existing JWKS URI).
- Short exp (5 min) despite §2.4 saying SHOULD NOT include exp,
  because leaving it open-ended creates replay risk if the token
  is intercepted in transit. Single-use is enforced by the jti +
  events combination.
- sid is populated from sessionData.Nonce, which is the closest
  existing analogue of an OIDC session ID in our model.

New test file oidc_phase3_backchannel_logout_test.go:

- Spins up an httptest receiver, calls NotifyBackchannelLogout,
  asserts the JWT carries iss/aud/sub/sid/iat/jti, asserts nonce
  is absent, asserts the events map contains the BCL event key.
- Empty URI → error
- Missing both sub and sid → error

…n fallback

Two final pieces for Phase 3 that cross-cut all four groups:

Discovery wiring (openid_config.go):

- response_types_supported now advertises all 7 supported values
  including the hybrid combinations: code, token, id_token,
  'code id_token', 'code token', 'code id_token token',
  'id_token token'.
- claims_supported extended with auth_time, amr, acr, at_hash, c_hash
  (added by Phase 2 and Phase 1 respectively).
- backchannel_logout_supported and backchannel_logout_session_supported
  set to true IFF BackchannelLogoutURI is configured. Avoids lying
  to RPs that probe the discovery doc.

Secondary-key verification fallback (internal/token/jwt.go):

- ParseJWTToken now retries with the secondary key when the primary
  verification fails, IFF JWTSecondaryType is configured. This
  completes the Phase 3 manual rotation workflow end-to-end:
    1. Operator adds new key as --jwt-secondary-*
    2. JWKS publishes both keys (Group C)
    3. Verification accepts tokens signed by either (this commit)
    4. Operator swaps primary/secondary
    5. Outstanding tokens signed by the now-secondary key keep
       verifying — this was the gap Group C flagged as deferred
- Refactored the parse logic into a small parseJWTWithKey helper
  that takes (token, algo, secret, publicKey) so the primary and
  secondary paths share one implementation.
- New signing keys are always generated with the primary — the
  secondary is verification-only.

New tests in oidc_phase3_jwks_multi_key_test.go:

- TestParseJWTTokenFallsBackToSecondaryKey: mints a token signed
  with secondary RSA key material, asserts ParseJWTToken accepts
  it via fallback.
- TestParseJWTTokenRejectsUnsignedGarbage: ensures the fallback
  doesn't accept malformed tokens.

Updated TestOpenIDDiscoveryCompliance assertions already pass the
expanded response_types_supported list.

Code review follow-ups on Phase 3 (approved with nits):

- I-1 (Important): Fix introspection client_id passthrough. Previously
  copied client_id from the aud claim, which could be a JSON array
  for multi-audience tokens and would produce client_id as an array
  in violation of RFC 7662 §2.2. Set resp['client_id'] = h.Config
  .ClientID directly — the audience check above already confirmed our
  client_id is in the audience set, and the RFC says client_id is a
  string. Latent today (single-string aud), active once Phase 4 M2M
  lands.

- M-1 (Minor): Clarify --jwt-secondary-private-key / --jwt-secondary
  -public-key CLI help text to make it explicit that the private key
  is currently unused (verification-only) and only the public key is
  consumed by the verification fallback. Prevents operator confusion
  about what the secondary private key does during rotation.

With Phases 1-3 all merged, the 'phase' labels in filenames and
comments no longer carry useful information. Rename the integration
test files to semantic names that describe what they test, and
scrub 'Phase 1'/'Phase 2'/'Phase 3' labels from comments and test
fixture data.

File renames (internal/integration_tests/):
  oidc_phase1_userinfo_test.go      -> oidc_userinfo_scope_filtering_test.go
  oidc_phase2_id_token_claims_test.go -> oidc_id_token_claims_test.go
  oidc_phase2_logout_test.go        -> oidc_rp_initiated_logout_test.go
  oidc_phase2_authorize_test.go     -> oidc_authorize_params_test.go
  oidc_phase3_introspect_test.go    -> oidc_introspect_test.go
  oidc_phase3_hybrid_test.go        -> oidc_hybrid_flow_test.go
  oidc_phase3_jwks_multi_key_test.go -> oidc_jwks_multi_key_test.go
  oidc_phase3_backchannel_logout_test.go -> oidc_backchannel_logout_test.go

Identifier renames:
  createAuthTokenForPhase2Test -> createAuthTokenForIDTokenClaimsTest

Test fixture email prefixes:
  id_token_phase2_  -> id_token_claims_
  userinfo_phase1_  -> userinfo_scope_

Comment updates drop 'Phase N' labels from:
  internal/token/auth_token.go  (c_hash, acr comments)
  internal/token/jwt.go         (ParseJWTToken fallback comment)
  internal/http_handlers/authorize.go (prompt=consent comment + log msg)
  internal/integration_tests/oidc_authorize_params_test.go
  internal/integration_tests/oidc_id_token_claims_test.go
  internal/integration_tests/oidc_jwks_multi_key_test.go

Pure cosmetic change. No functional deltas. Full test suite green.