API keys: a service principal with capability scopes and overlapping rotation

An API key can only reach the content API, and it acts as whoever created it. `barakoCMS/Infrastructure/Auth/ApiKeyScopeProcessor.cs:44-54` maps `/api/contents`, `/api/content-types` and `/api/schemas` to scopes and returns null for every other path, which `:31-36` denies. So no key reaches files, roles, workflows, connectors, module endpoints, the pages tree or export. `barakoCMS/Infrastructure/Auth/ApiKeyAuthenticationHandler.cs:63` loads `key.UserId`, the creator, and `:77` takes that user's roles in the tenant at request time. `barakoCMS/Features/ApiKeys/Endpoints.cs` offers create, list and revoke (`:37`, `:99`, `:133`) and nothing else.

### Why it matters

An integration (a booking service writing to a clinic's calendar, an agent driving barista) needs a key that can upload a file or run a workflow, and that keeps working when the admin who made it leaves. Today removing that admin's membership silently kills every integration they created, and replacing a key means a moment where the old one is revoked and the new one is not yet deployed. #831 and #833 assume per-service keys, and barista (#801) and #345 say an agent holds a scoped key.

### The general concept

A service principal per tenant that owns API keys, holds its own roles, and is not a person. Scopes are capabilities, so any endpoint gated by a capability is reachable by a key granted it. A key can be rotated with an overlap window where both old and new work.

### Where it lives

Core: auth, API keys and capabilities.

### Compatibility

Released, and it changes stored keys. Existing keys keep their content scopes and keep resolving roles from their creator until they are moved to a service principal, which a migration can do per tenant. Adding reachable paths loosens nothing an existing key could do. Relates #653.

### Done when

- A key granted the file upload capability can upload a file, and a test showing that is refused today.
- A key owned by a service principal keeps working after the admin who created it loses their membership.
- Rotating a key leaves both keys valid for the overlap window and only the new one after it.

Found in the architecture sweep of 15 September 2026.

Start with ApiKeyScopeProcessor.cs:31-54, ApiKeyAuthenticationHandler.cs:63-77, and Features/ApiKeys/Endpoints.cs at lines 37, 99, and 133 to map current scope, ownership, and lifecycle behavior. Trace the related stored-key migration and capability checks before designing service-principal ownership. Done means file upload authorization, continued access after creator membership removal, and the specified overlapping rotation behavior are covered by tests.

Written by the indexing model from the issue text.