HAIP 1.1: change x509_hash from "MUST use" to "MUST support" so attested verifier instances are not foreclosed

Section 5 requires: "For signed requests, the Verifier MUST use, and the Wallet MUST
accept the Client Identifier Prefix x509_hash". "MUST use" does not merely set an
interoperability floor; it forbids a Verifier from using any other mechanism even
inside an ecosystem whose wallets support one. The request here is surgical: in HAIP
1.1, change "MUST use" to "MUST support", keeping x509_hash as the mandatory baseline
every wallet and verifier implements, while permitting ecosystems to additionally use
verifier_attestation or openid_federation where bilaterally supported.

This is deliberately narrower than #88, which proposed adding or mandating OpenID
Federation at the organizational level and was closed for lack of consensus to
mandate, with wallet complexity as the recorded concern. This proposal adds zero
mandatory-to-implement surface for Wallets. It was also noted there that the WG's
direction meant dropping verifier attestation; we understand that as dropping it as a
mandate candidate while its attester trust was undefined. That gap is now being
addressed concretely: we have proposed in openid/federation-wallet#60 that the
attestation issuer be resolved through a Trust Chain, with the instance bound to the
organizational Credential Verifier that carries registered entitlements.

Two developments since #88 motivate revisiting, as its closing comment anticipated:

1. Verifier instances. Presentations are increasingly made to mass-deployed
   verifier software (POS terminals, mobile readers, proximity readers) with
   per-device keys and no resolvable identity. Under "MUST use x509_hash" their
   trust reduces to CA roots baked into wallet builds. The EUDI ARF's per-instance
   access certificates confirm the requirement while duplicating PKI outside any
   dynamic trust fabric; #371 documents the same pressure from New Zealand, where
   verifiers sit outside the trust framework entirely.

2. x509_hash already depends on external trust infrastructure. As raised in #243
   (unanswered), x509_hash provides no binding between the client identifier and
   redirect_uri/response_uri; that binding "must be established externally (e.g. by
   trust registries)". The mandated mechanism therefore already presupposes exactly
   the out-of-band trust registry function this proposal would let ecosystems
   operate in a standardized, resolvable form.

If the WG prefers HAIP itself to remain x509-only even at the "MUST support" level,
we will take up the alternative already suggested in #88 (a federation profile
layered on HAIP) and contribute it, including conformance test text. But correcting
the base profile avoids each ecosystem shipping "HAIP but with one thing changed",
the outcome #371's discussion argued against.

Start with Section 5's signed-request requirement, then read the linked discussions in #88, #243, and #371 for the unresolved interoperability and trust concerns. Review openid/federation-wallet#60 for the proposed Trust Chain approach; the work is complete when the WG reaches agreement on the normative HAIP 1.1 wording and its federation implications.