Add optional permission scopes to API tokens

A token may carry a scopes list: it then grants only those permissions,
intersected with what the owner holds at use time, with the admin role
bypass suspended and role-gated routes denied - a scoped token from an
admin account is genuinely limited. Scope ceiling enforced at
create/update too (only permissions the owner holds; 400 lists
violations) and the picker only offers what you hold. Token management
itself now requires the new apitokens.create permission (admin by
default, grantable via roles). Unscoped tokens keep the exact prior
act-as-owner behavior; imports need an unscoped admin token.
Migration 7d22.

756 tests pass; live-verified scoped 201/403 matrix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -29,6 +29,25 @@ ADR-007 and ADR-002.
   with a create modal that reveals the secret once (copy button) and an admin
   All Tokens section. Docs: `docs/IMPORT-API.md` and `docs/CONFIG.md` updated to
   recommend a PAT for imports. Core feature; no plugin-contract change.
+- Optional permission scopes on personal API tokens. A token MAY carry a scopes
+  list (permission names, migration `7d22_apitokens_scopes` adds the nullable
+  `apitokens.scopes` JSON column); NULL keeps the original behavior (acts as its
+  owner). A scoped token grants ONLY the listed permissions, intersected with
+  what the owner actually holds at use time, and SUSPENDS the admin-role bypass,
+  so a scoped token minted by an admin is genuinely limited: it is denied on
+  role-gated (`require_role`) endpoints and gets no import mode. The shim mints
+  the request JWT with a `patscopes` claim that `require_permission`,
+  `require_role`, and `import_mode_active` read; normal login JWTs carry no such
+  claim and are unaffected (zero regression). Scopes are validated at write time
+  against the token OWNER's permissions (the scope ceiling - a token can never
+  grant more than its owner holds; when an admin edits another user's token the
+  ceiling is that owner's permissions), rejecting unknown or unheld names 400.
+  Minting/managing tokens now requires the new `apitokens.create` permission
+  (category `apitokens`; admins hold it by default, grantable via the roles UI)
+  rather than being open to any authenticated user. The Settings > API Tokens
+  create/edit modals gain a "Restrict permissions" section (a category-grouped
+  checkbox grid limited to the permissions the creator holds) and the token
+  lists show a full-access / N-permissions access chip.
 - Vendor-model photos on asset detail heroes: computers and printers now
   surface the linked model's `imageurl` in their extension payloads (the
   field machines already exposed), and the machine, PC, printer, network