Define credential registration and rotation lifecycle

## Objective

Split issuer credential registration, update, and rotation into clear authorization-controlled workflows.

## Current State

`POST /api/v1/credentials` registers issuer public keys. There is an existing broad issue (#187) about issuer registration ownership. This sub-issue narrows the implementation path so registration and rotation can be worked in smaller PRs.

## Deliverables

- [ ] Define whether first-time registration is public, admin-only, or invitation/onboarding-token protected.
- [ ] Add a separate authenticated credential update/rotation workflow.
- [ ] Prevent accidental overwrite or issuer takeover.
- [ ] Add audit-friendly error cases for duplicate issuer, wrong issuer, malformed JWK, and unsupported key type.
- [ ] Document the chosen lifecycle in README/OpenAPI.

## Acceptance Criteria

- [ ] First registration and later rotation have distinct rules.
- [ ] Existing issuers cannot be taken over by posting a new JWK.
- [ ] Rotation is authenticated and issuer-bound.
- [ ] Tests cover duplicate registration and authorized/unauthorized rotation.

## Verification

- [ ] Handler/service tests
- [ ] OpenAPI updated
- [ ] Demo workflow updated or added

Start by finding the implementation behind `POST /api/v1/credentials` and tracing it into the service layer. Compare the current registration path with update logic, then define and separate first-time registration and authenticated rotation behavior with checks for duplicate/wrong issuer and bad JWK/key-type cases. Review and extend handler/service tests for duplicate registration and authorized vs unauthorized rotation, then update README and OpenAPI to document the two lifecycle flows. Completion is when both paths are enforced with tests and docs reflecting the new rules.

Escrita pelo modelo de indexação a partir do texto da issue.