Document the dashboard API Keys management page

The dashboard's API Keys page (list plus Create/Rotate/Revoke and the
create dialog) had no design-doc coverage even though Authorization.md
already documents the constraint model it exposes. Add an "API keys
page" section to GatewayDashboardDesign.md describing the table columns,
the LDAP-group-gated management actions, the one-time secret reveal, and
audit logging. Cross-link it from the constraint-enforcement section of
Authorization.md and the CLI section of Authentication.md so the two
key-management surfaces reference each other.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/GatewayDashboardDesign.md

@@ -49,6 +49,7 @@ Endpoint layout:
 /dashboard/workers
 /dashboard/events
 /dashboard/galaxy
+/dashboard/apikeys
 /dashboard/settings
 /dashboard/_blazor
 ```
@@ -83,6 +84,7 @@ MxGateway.Server
         SessionDetailsPage.razor
         WorkersPage.razor
         EventsPage.razor
+        ApiKeysPage.razor
         SettingsPage.razor
       Shared/
         MetricCard.razor
@@ -91,6 +93,9 @@ MxGateway.Server
     DashboardSnapshotService.cs
     DashboardAuthorizationHandler.cs
     DashboardAuthenticator.cs
+    DashboardApiKeyAuthorization.cs
+    DashboardApiKeyManagementService.cs
+    DashboardApiKeySummary.cs
     DashboardSnapshot.cs
     DashboardSessionSummary.cs
     DashboardWorkerSummary.cs
@@ -249,6 +254,52 @@ Show aggregate event diagnostics:
 Do not display full tag values by default. If value display is later added, make
 it opt-in and redacted.
 
+### API keys page
+
+`/dashboard/apikeys` lists the gateway's API keys and, for authorized
+operators, manages them. It reads key metadata through the same
+`IApiKeyAdminStore` the `apikey` CLI uses, so the dashboard and the CLI act
+on one source of truth.
+
+The table shows one row per key:
+
+- key id,
+- status (`Active` or `Revoked`),
+- display name,
+- scopes,
+- constraints (rendered as `unconstrained` when none are set),
+- created timestamp,
+- last-used timestamp.
+
+Key secrets are never listed. Only the peppered hash is stored, and the page
+never reconstructs a key. See [Authorization](./Authorization.md#constraint-enforcement)
+for what each constraint means and how it is enforced on the gRPC path.
+
+#### Management actions
+
+Create, Rotate, and Revoke controls render only when the signed-in user is
+authorized. `DashboardApiKeyAuthorization.CanManage` requires an authenticated
+principal that is a member of the LDAP `MxGateway:Ldap:RequiredGroup` — the
+same group the dashboard login enforces. An anonymous localhost viewer can read
+the table but sees no action controls.
+
+- **Create** opens a dialog for the key id, display name, scope checkboxes
+  (the `GatewayScopes` catalog), and the optional constraint fields: read and
+  write subtrees, read and write tag globs, browse subtrees, max write
+  classification, and the read-alarm-only / read-historized-only flags.
+- **Rotate** issues a new secret for an existing key id and invalidates the
+  old one.
+- **Revoke** marks a key revoked; a revoked key cannot be un-revoked.
+
+Create and Rotate return the assembled `mxgw_<keyId>_<secret>` token **once**,
+in a one-time banner. It is never shown again, so the operator must copy it
+immediately. This mirrors the `apikey create-key` / `rotate-key` CLI.
+
+Every management action appends an `api_key_audit` entry
+(`dashboard-create-key`, `dashboard-rotate-key`, `dashboard-revoke-key`) with
+the key id and the caller's remote address. Secrets and pepper values are never
+logged.
+
 ### Settings page
 
 Show read-only effective configuration: