fix(security): bind cnf.jwk to the trusted signing key

[imran-siddique]

Why

TRACE §3.2.2 defines the signature binding as a signature made by the key in cnf. The verifier required a trusted key and verified the signature with it, but did not require signed cnf.jwk to name that same key. A trusted signer could therefore authenticate a record that directed downstream proof-of-possession checks to an unrelated key.

What changed

• derive RFC 7638 thumbprints for the trusted and embedded keys
• require both thumbprints to match before accepting the signature
• validate the embedded key as Ed25519
• compare key identity while ignoring optional JWK metadata such as kid and use
• preserve revocation checks against the trusted key before inspecting the embedded key
• clarify the two-key trust and binding process in both verification guides

Verification

• focused signature tests: 47 passed
• full suite: 326 passed, 1 skipped
• ruff check src tests
• mypy src/agentrust_trace
• git diff --check

Regressions cover a valid trusted signature naming another confirmation key, missing cnf.jwk, optional trusted-key metadata, wrong trusted keys, tampering, public-key objects, and revocation ordering.

[lywinged]

Noting a convergence rather than raising an objection, because it happened twice in eleven hours and that is the interesting part.

This PR compares jwk_thumbprint(embedded_jwk) against jwk_thumbprint(trusted_jwk) in sign.py, ignoring optional JWK metadata. #149, opened eleven hours earlier, does the same comparison in provenance.py for the same reason: a JWK is identified by its key material and kid carries none of it. Different files, different defects, no textual conflict, and the same technique arrived at independently by two people on the same day, in a package that already defines and exports jwk_thumbprint.

The near-term consequence is small and worth naming: when both land there will be two key-identity comparisons written separately. Whichever merges second is the natural place to reuse the first rather than restate it, and I am happy for that to be #149 — it is the smaller of the two and I can rebase it onto whatever this lands.

The longer-range version of the same observation, offered as an observation and not a proposal. Three code paths verify something signed; they share _canonical_bytes and _pubkey_from_jwk and nothing above them. What sits above them has diverged: sign.verify_record consults revocation, provenance.verify_record contains the string revocation zero times, and §3.2.1 puts that requirement on a verifier rather than on one format. Key identity has now diverged and been re-converged by hand. Freshness is bounded in both but separately, and this PR's sibling #155 changes it in one of them.

I am not proposing the refactor. An envelope layer owning canonical bytes, key resolution, revocation and freshness would couple the release cadence of modules that currently ship independently, and content_marking would use a fraction of it. That trade is a scheduling decision and it is yours, not mine. What I can contribute is the evidence that the gap is costing something: two defects and now one duplicated fix, all inside a week.