feat(openid4vci): give key resolution the proof context, bind attested keys

[luisgf]

Closes #150.

ResolveProofKey saw only the kid, and that is blind exactly where the EU ecosystem
lives. In the attested-key form a wallet sends {typ, alg, kid, key_attestation} and the
key that signed the proof is inside the header — one of the attestation's
attested_keys. A callback holding only the kid cannot reach it, so the consumer
base64url-decoded the proof header itself before calling in: openvc decoding a header
once and the caller decoding it again, two implementations of "what is a header", one of
them free to drift.

The two spec facts that decide the shape

• App. D: "If used with the jwt proof type, the Credential Issuer MUST validate
  that the JWT used as a proof is signed by a key contained in the attestation in the
  JOSE Header." A MUST that applies to us and that we could not express.
• The jwt proof type fixes no rule for how a kid names a key inside
  attested_keys. The spec's own example uses "kid": "0" — an index; wallets also use
  each JWK's kid member, or an RFC 7638 thumbprint.

So: parse in, bind in, trust out. The mapping stays the caller's — guessing between
three conventions is the same "silently prefers one" defect the exactly-one-key-parameter
rule exists to prevent, and a wrong guess picks the wrong key out of a list the attacker
supplied.

What changed

verify_credential_request_proofs(..., resolve_proof_key_in_context=) takes a frozen
ProofKeyContext (kid, alg, a read-only header, the parsed key_attestation,
credential_issuer, index), so the resolver is one line of the caller's own rule:

resolve_proof_key_in_context=lambda ctx: ctx.key_attestation.attested_keys[int(ctx.kid)]

Pass it or resolve_proof_key, never both. ResolveProofKey is unchanged and not
deprecated — existing resolvers keep working untouched, and a context object grows
without ever breaking them again. Widening the alias to (kid, header) would have been a
MAJOR, and openbadgeslib pins openvc-core>=1.21,<2, so 2.0.0 would lock the reporting
consumer out of its own fix; inspect-based arity dispatch would silently downgrade a
resolver wrapped in cache.cached_resolve, which returns a one-arg closure, losing the
header with no error.

Also public: peek_key_attestation → UnverifiedKeyAttestation, and peek_proof_header,
so no caller writes that second decoder. Structure is validated, trust is not — typ,
exp and the signature stay on header/claims because they are a verifier's decisions
and that verifier needs a wallet-provider anchor openvc has no model for (ADR-0007 D9,
amended here by a 1.24.0 addendum).

Behaviour change

A proof carrying key_attestation must now be signed by one of its attested_keys
(RFC 7638 thumbprint, every key source), and a malformed attestation rejects the proof
before any crypto rather than being read at the end. Previously the header was captured
verbatim and never looked at; the pinned test asserting that is rewritten.

That check stops no attacker, and the docstring, threat-model I19 and Security-Model
say so — selling it as a defence would make the security story worse. Whoever forges a
proof also chooses its key_attestation, whose signature nothing here verifies, so they
attest their own key. It catches an honest wallet — or the caller's own resolver —
handing over a key the wallet never claimed, which would otherwise mint a credential
bound to the wrong key and verify cleanly. It can only reject, never accept, which is the
only reason an unverified blob may drive it.

Who breaks, all previously accepted:

• an attestation that is not a parseable JWS, or whose attested_keys is
  missing/empty/not an array of objects;
• x5c or kid deployments whose attestation does not list the key the chain or the
  registry produced — including the sharp one: jwk_thumbprint digests the coordinate
  strings as given, so a JWK with non-fixed-width x/y (non-conformant per RFC 7518
  §6.2.1.2, ~1 in 256 per coordinate — rare enough to pass every test and surface in
  production) thumbprints differently from the same key encoded correctly. The rejection
  names that cause and a test pins it.

No key proof that used to be rejected is now accepted.

Two error paths are typed rather than left to escape: InvalidKey is a key-backend error,
not a ProofError, and it is reachable from both sides of the comparison — a hostile
attested_keys entry, and the caller's own resolver returning something like
{"kty":"EC","crv":"P-256","x":123}, which passes the alg binding because that reads only
kty/crv. Both are wrapped into ClaimsInvalid.

Vectors, and the gap that remains

spec/key-attestation-app-d.json holds App. D's attestation and the proof that indexes
it. Both spec examples are printed decoded and the proof's attestation is a
placeholder, so what is third-party is the shape; the test re-encodes them and the
fixture's provenance says exactly that. The fixtures README records what is still
missing: no attestation from a real wallet provider exists here, and the binding is on
by default, so the ecosystem form it governs is pinned only by material this repo shaped.
The recorded EUDI metadata advertises key_attestations_required on all 27
configurations, which is how likely it is that a real one differs in some way that
matters.

examples/13_oid4vci_key_attestation.py runs the whole flow and is executed by CI.

Still open

require_key_attestation — a presence check, meaningful only now that the binding exists
(alone it is satisfied by "key_attestation": "x"). Left out: it is the issuer's own
metadata policy, and if proof.key_attestation is None: raise after the call expresses
it. Say the word and it lands.

Gate

flake8 clean over src/, tests/, examples/; mypy clean; 1626 tests passing,
26 skipped.