Status list aggregation endpoint: pagination, limits, and per-issuer quota

## Objective

Add pagination parameters (`limit`, `cursor`), pagination response metadata, and per-issuer active list quotas to prevent unbounded memory usage and DoS on `GET /api/v1/status-lists/aggregate`.

## Context

Currently, `get_aggregation` in `src/server/handlers/status_list/aggregation.rs` loads all status list URIs in a single database query without limits or pagination. If the system contains thousands of lists, a single aggregation request attempts to load and serialize all of them into a single massive JSON response, risking out-of-memory errors and server degradation.

Furthermore, there is no quota restricting the number of active lists an issuer can create, enabling list spamming.

## Deliverables

- [ ] Add query parameters `limit` (default 50, max 200) and `cursor` (keyset pagination on `list_id` or creation timestamp) to `GET /api/v1/status-lists/aggregate`.
- [ ] Update `list_uris` port and repository implementations (SQL and memory) to support paginated queries.
- [ ] Update `AggregationResponse` to include pagination metadata (`status_lists`, `next_cursor`, `total_count`).
- [ ] Add an operator-configurable per-issuer active list quota (e.g. `limits.max_lists_per_issuer`, default 1000) enforced during list publication.
- [ ] Update `docs/openapi.yaml` with the paginated aggregation schema.
- [ ] Add tests for paginated retrieval and quota enforcement.

## Acceptance Criteria

- [ ] `GET /api/v1/status-lists/aggregate` supports `limit` and `cursor` and never returns unbounded result sets.
- [ ] Requests exceeding the issuer list quota are rejected with `400 Bad Request` or `429 Too Many Requests`.
- [ ] Aggregation endpoint is safe against list spamming and memory exhaustion.

## References

- `src/server/handlers/status_list/aggregation.rs`
- `src/domain/ports.rs`
- Arc review: `arc-review/finalReview/resource-bounds-and-aggregation/README.md` (PoCs 1–4)