OIDCC/FAPI1/FAPI2/FAPI-CIBA client: publish unusable keys in the Issuer's JWKS in all RP tests

The Issuer now publishes its real signing key alongside five unusable keys (each with a distinct kid) in server_public_jwks, served from jwks_uri in every OIDCC RP test. A conformant relying party must ignore keys it cannot use and verify the id_token signature using the real key, per RFC 7517 section 5 - the steady state during any algorithm transition, e.g. an Issuer adding post-quantum keys before all relying parties support them.

The five keys cover each point at which an RP may have to skip a key:

• a post-quantum-shaped key (kty=AKP, non-existent ML-DSA parameter set) and a key with a made-up kty: skipped when the JWK Set is parsed
• an RSA key and an EC key (valid RFC 7517 A.1 key material) with unknown algs: parseable, skipped when the verification key is selected
• an EC key with an unknown crv: parseable, skipped when key import fails

Publishing the keys in every test rather than only in a dedicated module follows the AugmentRealJwksWithDecoys pattern from the FAPI2 client tests and makes the check independent of any JWKS caching in the RP - whatever copy of the JWKS the client holds, it contains the unusable keys. The kid-absent modules are the deliberate exception: they replace configureServerJWKS() with tightly-controlled key sets whose semantics depend on exactly which keys are published (an RP may reject a multi-key no-kid JWKS).

• AddUnusableKeysToServerPublicJwks condition (+ unit test); adds the keys to the published JWKS only, leaving the real signing key in server_jwks intact; called from AbstractOIDCCClientTest.configureServerJWKS() so the key-rotation modules re-add them whenever they regenerate the JWKS

Discussed with relevant working groups already:

https://github.com/openid/connect/issues/2147

https://github.com/openid/fapi/issues/851

closes #1937 (closed)