EPIC: Issuer registration ownership story for public credentials endpoint

## Objective

Replace the open `POST /api/v1/credentials` endpoint with a registration flow that proves an issuer is authorized to claim a given issuer identifier, supports key rotation, and can recover from key compromise before production.

## Context

The issuer registration endpoint is currently public and allows any caller to register a JWK under an arbitrary issuer id. Before production we need a clear ownership story.

## Candidate strategies

| Strategy | What it proves | Strengths | Weaknesses |
|---|---|---|---|
| **Admin / out-of-band pre-registration** | Operator trusts the issuer | Simple, strong control | Manual, does not scale |
| **Domain validation challenge** | Control of a DNS domain or web origin | Scalable, well-understood (ACME-style) | Requires a public web presence/TXT record |
| **Reverse-domain identifier + domain proof** | Same as above, but issuer id encodes the proven domain | Self-describing, prevents squatting | Ties identifier to domain |
| **DID-based proof** | Control of a decentralized identifier | Crypto-native, portable | DID resolution complexity |
| **Trusted issuer registry / federation** | Issuer is listed in an external trust list (e.g., EUDI Trusted Issuers, OpenID Federation, EBSI) | Industry-aligned | Requires external registry |
| **mTLS / client certificate** | Certificate from an approved CA | Strong authentication | Harder to rotate, less dynamic |
| **Server-assigned UUID** | Server owns identifier namespace | Prevents squatting, trivial to implement | No semantic identifier |
| **Multi-key lifecycle** | Existing key authorizes new keys / recovery | Enables rotation and compromise recovery | Needs history/audit log |

## Recommended phased approach

1. **Phase 1 — Identifier claim with proof**
- Support two identifier modes: **server-assigned UUID** and **reverse-domain** (`com.example.product`) when the caller passes a domain-validation challenge.
- Implement a challenge endpoint: server issues a nonce, caller returns it as a signed JWT or places it at a well-known location; server verifies control.
- Keep `POST /api/v1/credentials` but add a required `proof` field and/or split into `/api/v1/credentials/register` and `/api/v1/credentials/complete-challenge`.

2. **Phase 2 — Trusted issuer registry**
- Accept registrations only for DIDs or domains present in a configured trusted-issuer registry.
- Cache registry entries and refresh periodically.

3. **Phase 3 — Key rotation and compromise recovery**
- Allow multiple JWKs per issuer (`kid`-tagged).
- New keys can be added only when signed by an existing valid key with a configurable overlap/grace period.
- Support a recovery key registered at onboarding (offline), or an operator-initiated key replacement flow.
- Publish a revocation/ rotation notice endpoint for relying parties.

## Deliverables

- [ ] ADR (`docs/adr/0003-issuer-registration-ownership.md`) selecting the strategy.
- [ ] Update `POST /api/v1/credentials` (or add new endpoints) to require ownership proof.
- [ ] Implement domain/DID challenge-response flow.
- [ ] Add support for multiple keys per issuer with `kid` management.
- [ ] Add key rotation and recovery endpoints.
- [ ] Store key history and revocation metadata.
- [ ] Add comprehensive tests for squatting, rotation, recovery, and replay attacks.
- [ ] Update `README.md`, OpenAPI spec (#147), and trust model doc (#177).

## Acceptance Criteria

- An unauthenticated caller cannot claim an arbitrary issuer identifier without proof.
- Domain-based issuer ids require control of the corresponding domain.
- Key rotation does not invalidate previously issued, unexpired tokens during the overlap period.
- A compromised key can be revoked and replaced.
- The trust model document (#177) explains the chosen ownership model.