feat(security): clés d'API (ADR-0070, #665)

[rolljee]

Implémente la v1 retenue dans l'ADR-0070 (#1246, sur laquelle cette PR est empilée).

⏸ À ne pas fusionner avant la fin de la QA de console-v5 : une fusion sur 5-dev redéploierait ce que l'équipe est en train de tester.

Ce que ça ajoute

• /security/users/:id/api-keys : les clés d'un utilisateur (security:*). On y arrive par l'icône clé de sa ligne ou par le bouton « API keys » de sa page.
• « My API keys » dans le menu de session, sur /api-keys (auth:*). Les deux écrans partagent le même composant, ApiKeyList.
• Création :
  • la description est obligatoire ;
  • l'expiration se choisit parmi 7 j, 30 j, 90 j (par défaut), 1 an et « sans expiration », ce dernier choix avec un avertissement.
• Jeton montré une fois, avec un bouton de copie. La fenêtre ne se ferme ni par Échap, ni d'un clic à côté, ni par la croix : seulement par « I've copied it ». Le jeton n'est conservé nulle part (store, storage, toast, logs).
• Liste :
  • description, échéance relative (date exacte au survol), empreinte abrégée ;
  • les clés expirées et celles sans expiration sont marquées ;
  • filtre par description ;
  • l'empreinte est masquée sous md.
• Révocation unitaire, après une confirmation qui nomme la clé.
• Droits : six getters dans auth.ts. Rien n'est proposé sans droit, à une session anonyme, ni sur un backend v1.

Garde-fou

• Nouvelle spec apiKeys.spec.js (7 tests), ajoutée à la matrice de checks.yml. CLAUDE.md passe à 18 specs.
• Elle vérifie que le jeton :
  • authentifie bien en tant que l'utilisateur ;
  • ne figure ni dans la page après fermeture, ni dans le localStorage ou le sessionStorage ;
  • n'authentifie plus après révocation (401).
• En local, sur un build et une stack neuve : apiKeys 7/7, users 20/20, login 22/22.
• test:lint, test:types et les trois check:* passent.

Refs #665

🤖 Generated with Claude Code