spec(§8.4.3): Agent Card signature verification permits signer-controlled trust root via jku

§8.4 defines Agent Card signing over an RFC 8785 JCS payload — a solid mechanism. But the verification procedure in §8.4.3 selects the trust root from signer-controlled input, which undermines the authenticity guarantee the signature is meant to provide.

**Where.** §8.4.2 lists `jku` as a protected-header field the signer populates. §8.4.3 step 2 then instructs the verifier to:

> "Retrieve the public key using the `kid` and `jku` (or from a trusted key store)"

**The problem.** `jku` travels inside the artifact's own signer-controlled protected header. A verifier that follows step 2 literally fetches the verification key from a URL the signer chose. An attacker therefore signs a forged card with a freshly generated key, sets `jku` to their own JWKS, and the card verifies — the signer has nominated its own trust root (CWE-863, trust-boundary violation). The "(or from a trusted key store)" alternative is offered with equal weight and is not required, so the unsafe path is spec-conformant. The §8.4.3 Security Considerations cover HTTPS retrieval, key expiry/revocation, and multi-signature rotation, but not trust-root selection.

**Already validated downstream.** a2aproject/a2a-go#368 adopted a normative `KeyResolver` constraint for exactly this (commit `f6229c312`): *"The trust root MUST be selected by verifier-side policy. Implementations MUST NOT use the signer-supplied `jku` to select or fetch the trust root… `kid` MAY be used to select among keys enrolled out-of-band through a verifier-controlled path… The same constraint applies to `x5u`."* The spec should carry the same constraint so every SDK is safe by default, not just this one.

**Proposed normative text for §8.4.3:**

> Key discovery MUST be controlled by verifier-side policy. A verifier MUST NOT use a signer-supplied `jku` (or `x5u`, if later added) from the protected header to select or establish the trust root. `kid` MAY be used to select among keys already enrolled through a verifier-controlled path (a configured JWKS endpoint, DANE/TLSA anchor per #2043, or a trusted key store). A verifier that resolves keys by URL MUST constrain the target to a verifier-side allowlist.

Optionally, reclassify `jku` in §8.4.2 as an informational hint rather than a retrieval instruction. This is complementary to the identity/anchoring proposals in #1672 and #2043 — it fixes the verification procedure those mechanisms all rely on.