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

[RalphBragg]

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; Discovery of public key / certificates of Verifier by Wallet #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 reasons for using x509_hash instead of x509_san_dns? #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.

[lj-raidiam]

+1. It's time to get this into HAIP 1.1 (or as an alternative profile) given ecosystems beyond EUDI need it now. The Must use -> MUST support keeps the x509_hash as the mandatory letting existing ecosystems while upgrading to 1.1 choose the x509 only or additionally the attestation and/or federation path.

A minor remark: The trust in the verifier-attestation issuer shouldn't be tied to federation alone. openid/federation-wallet#60 relates to federation but the attester may be trusted by other means e.g. trusted lists.

There are also a couple of other things from #88 worth revisiting for 1.1.