Run the OpenID conformance suite against a pinned release topology

## Context

Conformance-suite evidence is the strongest public signal that applicable OpenID and OID4 claims hold. The evidence must be reproducible from pinned release images and configuration, not depend on a mutable hosted lab or on a second repository remaining available.

The current wallet-delivery surface is the supporting **registry-evidence-oid4vci** adapter and its frozen OID4VCI 1.0 Final profile for holder-bound Evidence. Historical Registry Notary OID4VCI behavior is retired and is not a conformance target.

A Solmara Lab topology may be used to exercise the run, but the harness and recorded evidence belong with the release surface they verify.

Related: #57, #689, #690.

Pinned #690 interoperability evidence: [committed receipt at `68af5eb9`](https://github.com/registrystack/registry-stack/blob/68af5eb9ed8b779afdbaf33aa1efda06ed88026c/products/evidence/fixtures/interoperability/inji-oid4vci/receipt.json). This receipt records bounded interoperability evidence for the exact pinned Inji revisions and focused test conditions. It is not OpenID conformance or certification.

## Scope

- Identify the stable OpenID conformance plans that apply to Registry Stack's OIDC bearer-validation resource servers, Registry Mint authorization-server role, Evidence verifier behavior, and the narrow Evidence OID4VCI adapter.
- Map each plan to an exact shipped role and profile. Record exclusions where the suite assumes capabilities Registry Stack deliberately does not implement.
- Run applicable plans against a pinned release topology with scripted, documented setup.
- Include at least one Relay or Evidence resource server using OIDC bearer validation rather than API-key-only demo authentication.
- Include OID4VCI plans only when the suite provides stable plans applicable to the frozen profile in #689. Do not run historical Notary plans or imply full issuer support.
- Keep #690's pinned Inji interoperability evidence distinct from conformance-suite evidence. One does not substitute for the other.
- Record the initial result set honestly. Fixing every failure can be follow-up work unless a failure contradicts a shipped profile claim or exposes a security defect.

## Acceptance criteria

- [ ] A fresh runner can reproduce the suite invocation from pinned images and checked-in non-secret configuration.
- [ ] The applicable-plan mapping names the exact Registry component and frozen profile each plan evaluates.
- [ ] Historical Registry Notary OID4VCI behavior is explicitly excluded.
- [ ] Unsupported grants, credential formats, DID resolution, persistence, and lifecycle features are documented as exclusions rather than implemented for the suite.
- [ ] Initial results are committed as release evidence with failures and unsupported cases explicit.
- [ ] Inji interoperability evidence from #690 is referenced separately and is not described as conformance or certification.
- [ ] No credential, private key, code, nonce, token, proof, selector, subject identifier, or live response appears in logs or committed evidence.
- [ ] Release gating does not require a live hosted-lab dependency.
- [ ] Suspected security defects found during conformance are routed through **SECURITY.md** before any public result describes them.

## Security note

Conformance harnesses cross authentication, proof, nonce, signing, and disclosure boundaries. Use sanitized subjects and non-secret configuration, preserve the shipped profile rather than enabling test-only protocol modes, and report suspected vulnerabilities through **SECURITY.md**.

Start with the scope and acceptance criteria, then read SECURITY.md and the pinned receipt at products/evidence/fixtures/interoperability/inji-oid4vci/receipt.json. Map the applicable plans to shipped roles and profiles, keeping #690 separate from conformance evidence and excluding historical Notary behavior. Done means a fresh runner can reproduce the pinned run and committed evidence contains explicit results, exclusions, and no secrets.

Written by the indexing model from the issue text.