[Feature] Scoped API keys for clan management actions (kick, ban, join requests)

## ✨ API/Database Feature Request

### Summary

Official, scoped API keys for clan management actions. Clan leaders can issue a revocable key that allows a script to call existing clan management endpoints (kick, approve/deny join requests, optionally ban) for their own clan. This gives moderation bots a sanctioned authentication path; today these endpoints are only reachable with the session token of a logged-in browser session, which scripts cannot obtain in any supported way.

## 📘 Use Case

We run a clan and want to built a Discord bot on top of the public API (docs/API.md). It detects when members with our clan tag play public team games solo, which drags down the weighted win score in the clan leaderboard, and posts an alert in our admin channel. Today a human leader then opens the clan modal and kicks manually. The natural next step is letting the bot perform the member management action itself, but there is no official way for a script to authenticate. Reusing a browser session token is brittle (token expiry) and, as we read section 5 of the ToS ("automated means or interface not provided by us"), not covered. So we are asking for a sanctioned path instead of doing it anyway. The same need applies to any clan running moderation or join-request automation.

## 📥 Example API Request

```
POST /clans/JR/api-keys
Content-Type: application/json
Authorization: Bearer

{
"label": "discord-mod-bot",
"scopes": ["kick", "requests"]
}
```

Then, using the issued key:

```
POST /clans/JR/kick
Content-Type: application/json
Authorization: Bearer

{
"targetPublicId": "abc123"
}
```

## 📤 Example API Response

```
// key creation
{
"id": "key_01",
"key": "ofc_live_...", // shown once
"clanTag": "JR",
"scopes": ["kick", "requests"],
"createdBy": ""
}

// kick via key
{
"status": "success",
"action": "kick",
"targetPublicId": "abc123",
"performedVia": "key_01",
"timestamp": "2026-09-05T18:00:00Z"
}
```

## 📦 Database Considerations

- **New Tables**: Yes. One table `clan_api_keys`: key hash, clan tag, issuing leader publicId, label, scopes, createdAt, revokedAt, lastUsedAt. Store only the hash, show the key once on creation.
- **Modified Tables**: No. Existing clan action handlers only need a second auth path that resolves a key to (clan, scopes, issuer).
- **Migrations Required**: Yes, one migration for the new table.
- **Indexes Required**: Yes, unique index on key hash, index on clan tag. Lookup is one indexed read per request, negligible load.

## 🔐 Security & Access Control

- Does the endpoint require authentication? Yes. Key issuance requires a logged-in clan leader; usage requires the Bearer key.
- Should it be limited to specific roles? Yes. Only leaders can issue/revoke keys. Keys are tied to one clan and to explicit scopes; suggested scopes: kick, requests (approve/deny), optionally ban. Destructive scopes like disband or promote should not be issuable at all.
- Any sensitive data? The key itself (hash at rest, show once). Actions performed via key should be attributed to the issuing leader for accountability, so misuse falls back on a responsible account. Same strict rate limits as the public API. Revoking the key or the leader losing their role invalidates it.

## 📎 Additional Context

The management endpoints already exist and are used by the web client (kick, ban, approve/deny, promote/demote in the clan modal). This request only adds an official authentication path for a safe subset of them. The read side is already well served by the documented public API, which we use and appreciate. Happy to provide more details or test an experimental version.

Start with docs/API.md and trace the existing clan management endpoints used by the web client, including their authentication and authorization paths. Map the required key lifecycle, scopes, migration, revocation, attribution, and rate-limit behavior before implementation. Done means a reviewed design and tests covering issuance, scoped use, revocation, role loss, and rejection of unauthorized actions.

Written by the indexing model from the issue text.