feat(eudi): revocable SD-JWT VC badges, the OpenID4VCI configuration entry, and the cryptography exception contract

[luisgf]

Three independent pieces of the post-v4 roadmap, each in its own commit.

feat(eudi) — revocable SD-JWT VC badges via IETF Token Status List (#270)

SD-JWT VC was the only one of the four tracks whose badges could not be revoked:
issuance refused a credential carrying a credentialStatus (#226 — the right call
while no interoperable JOSE-track revocation existed) and both verify paths hard-set
require_status=False. For an issuer whose product promises revocation that is a hard
stop, not a caveat: every badge sent to a wallet is one it can never withdraw, including
after a mistaken issuance or an erasure request.

• Issuance: issue_badge_sd_jwt(..., status=build_token_status_reference(uri=…, index=…))
  emits an always-disclosed status claim — excluded from the disclosable set even
  when the caller asks for it, because a holder able to withhold the pointer could present
  a revoked badge as an unrevokable one.
• Verification: require_status / resolve_status_list_token on both trust paths.
  The x5c path hands them to verify_credential (which owns status); the pinned-key path
  calls check_token_status itself, since the suite-level verify has no status stage.
  Revoked or suspended raises EudiError — and so does every way of not knowing: an
  unresolvable, wrongly-signed, expired or URL-swapped list is never read as "not revoked".
• status_list_token_resolver(pubkey_pem=…) builds the safe default resolver: HTTPS fetch
  (SSRF-guarded, size-capped) plus openvc-core's verify_status_list_token, including the
  IETF anti-swap sub check.
• Encoding, packing and signing stay openvc-core's; the [eudi] floor moves to >=1.23.

Gate: #245 was resolved as go — gates 2 and 3 met, gate 1 (the RFC) passed
deliberately on IESG approval plus a byte-pinned conformance suite, with #127 owning the
draft→RFC citation swap.

Two formats, two lists: a W3C credentialStatus (Bitstring) is still refused at
SD-JWT issuance rather than mapped — it points at a list an SD-JWT verifier cannot read,
so a badge issued on both tracks needs an index in each. #226's reasoning does not expire.

feat(eudi) — the OB 3.0 credential configuration entry for OpenID4VCI (#271)

badge_credential_configuration() returns the credential_configurations_supported
entry a wallet reads to request the badge, with the claim set derived from
badge_type_metadata() — so the Type Metadata document an issuer serves at the vct
and the configuration it advertises cannot drift from each other, or from what
issue_badge_sd_jwt() stamps. Pure dict building: no state, no I/O, no protocol, no
[eudi] extra.

Out of scope on purpose (deployment policy, one per tenant): the enclosing
/.well-known/openid-credential-issuer document, the Credential Offer, the Credential
Response, the nonce store.

fix(keys) — both cryptography exception contracts map onto the taxonomy (#244)

The floor was stale at >=42, but the real gap was underneath it:
KeyRSA/KeyECC.read_private_key/read_public_key and the Ed25519 loaders called
cryptography unguarded, so a corrupt or unsupported key PEM escaped as a raw
traceback. v47 changed the contract on top of that — an unsupported algorithm now raises
UnsupportedAlgorithm, which is not a ValueError.

All PEM loading now goes through one guarded pair of helpers mapping both contracts onto
PrivateKeyReadError / PublicKeyReadError (original kept as __cause__);
detect_key_type / ec_curve_from_pem stay total; KeyRSA.generate_keypair maps v48's
1024-bit floor to GenPrivateKeyError. Floor moves to >=45 (openvc-core's own pin, so
the extras resolve one range) and deliberately not to >=47 — both contracts are
handled and tested, so requiring an April-2026 release would buy nothing.

Verification

• pytest: 1389 passed, 1 skipped (was 1346 on master). flake8, mypy and
  gitlint clean.
• Each commit was checked out into a temporary tree and run on its own: 1366 and 1377
  passing respectively, so the history bisects cleanly.
• Implemented and tested against openvc-core 1.23.1, the current release.

Decisions recorded in the issues

The departures from the issue texts are written up in comments on #270 (the W3C-status
refusal as the case that stays unrepresentable; the status check living in different
places on the two paths; require_status defaulting off; the resolver factory; the Type
Metadata document deliberately left unchanged, since declaring status there would
invalidate every published vct#integrity pin) and on #271 (deriving claims from the Type
Metadata document; emitting the OpenID4VCI 1.0 Final layout rather than the EU reference
issuer's newer credential_metadata nesting).

Closes #270
Closes #271
Closes #244

Refs #226, #245, #248, #272.