Write ADR and API contract for issuer registration ownership

## Objective

Write the issuer registration ownership ADR and define the API/config contract before implementation work begins.

## Scope

This issue decides the first production-supported ownership model for issuer registration and turns it into an implementable contract for handlers, services, storage, OpenAPI, and operator configuration.

## Deliverables

- [ ] Add `docs/adr/0003-issuer-registration-ownership.md` or the next available ADR number.
- [ ] Decide the initial supported onboarding modes:
- server-assigned issuer identifier,
- reverse-domain issuer identifier with domain control proof,
- optional/admin-controlled registration path if needed for production rollout.
- [ ] Explicitly defer or accept DID proof, trusted issuer registry checks, mTLS, and federation integration.
- [ ] Define endpoint contracts for challenge creation, challenge completion, credential registration, and later credential/key updates.
- [ ] Define request/response/error semantics without leaking sensitive material.
- [ ] Define migration/deprecation behavior for the existing open `POST /api/v1/credentials` endpoint.

## Acceptance Criteria

- [ ] The ADR states the selected strategy and why alternatives are deferred or rejected.
- [ ] API contracts are clear enough for endpoint and storage implementation tickets to proceed independently.
- [ ] Backward compatibility or breaking-change behavior is explicit.
- [ ] The trust model document and OpenAPI update scope are identified.

Read existing ADRs in `docs/adr` to follow numbering/style, then draft `docs/adr/0003-issuer-registration-ownership.md` (or the next available) with the selected ownership model. Next inspect the current API contract/OpenAPI references and related flow docs for issuer operations, then define request/response/error semantics for challenge creation, challenge completion, credential registration, and credential/key updates. Finally, document operator/config and storage assumptions, and specify migration/deprecation for `POST /api/v1/credentials` with explicit backward-compatibility and deferred checks; done when the ADR and contracts are implementation-ready and unambiguous.

由索引模型根據 Issue 內容生成。