Limit each project to max 20 API keys

Owner directive (2026-08-25, ADR-0025 OQ-4 discussion): *"api-key here should never rate limit. But instead each project is limited to max 20 api-key."*

Part (b) of that directive — the lightbridge-authz half: `createApiKey` refuses when the project already holds 20 keys. Decisions for the implementer:
- Count ACTIVE keys only, or all non-deleted (incl. revoked)? Recommendation: active only — revoking should free a slot, that is what revocation is for.
- Error variant: `Error::Validation`/`Conflict` with a message naming the limit and the project.
- Hard-coded 20 vs config knob: directive says a number, house style dislikes dormant knobs — hard constant, `API_KEYS_PER_PROJECT_LIMIT: usize = 20`, with a doc comment citing this issue.
- Race: two concurrent creates at 19 keys must not both succeed — count inside the insert transaction with the project row locked (`SELECT ... FOR UPDATE` on projects), or a DB-side check.
- Test: seed 20, assert #21 refused; revoke one, assert create succeeds; concurrency test at the boundary.

Part (a) — API-key plane never rate-limits at the gateway — is an ai-helm-values policy change, tracked there.

## AI Usage Declaration
Filed by Claude to bank the directive with implementation notes; decisions above are recommendations, not settled.

Source of truth: owner statement quoted above.

Start at createApiKey and inspect the existing project-row locking, insert transaction, and error-handling paths. Add tests for refusing the 21st active key, allowing creation after revocation, and preventing concurrent creates from exceeding the limit. Done means the limit and project are named in the error and the boundary tests pass.

Written by the indexing model from the issue text.