Support issuer key history, status, and multiple active keys

## Objective

Support multiple issuer keys with `kid`, key status, history, and revocation metadata.

## Scope

This issue introduces the data model and service behavior needed for safe issuer key rotation and compromise recovery. It does not need to implement every rotation endpoint; it creates the foundation those flows depend on.

## Deliverables

- [ ] Extend storage/domain models to support multiple keys per issuer.
- [ ] Track `kid`, key material, status, creation time, activation time, retirement/revocation time, and audit metadata.
- [ ] Prevent duplicate active `kid` values for the same issuer.
- [ ] Define how token verification selects valid issuer keys during overlap windows.
- [ ] Add repository/service tests for active, retired, revoked, unknown, and duplicate keys.
- [ ] Add migrations for SQL backends where required.

## Acceptance Criteria

- [ ] Existing issuers cannot be silently overwritten by registering a new key.
- [ ] Multiple keys can coexist during a rotation overlap window.
- [ ] Revoked keys are not accepted for new operations.
- [ ] The model preserves enough history for audit and recovery.

## Dependencies

- Depends on the ADR/API contract issue.

## Related Issues

- Parent: #187
- Related: #320