feat(ra-console): gestion du registre des opérateurs depuis la console

[PhilippeVienne]

Objet

Gestion du registre des opérateurs depuis la console (docs/WEBUI.md §5, §10), suite des étapes 3 et 4. Empilée sur #67 (feat/ra-console-quorum) → #66 → #65 → #64. Ordre de merge : #64, #65, #66, #67, cette PR (rebase --onto origin/dev <ancienne tête> à chaque étape).

ra-console relaie, sur le schéma exact des étapes 3 et 4 (challenge par POST /api/v1/webauthn/challenge, puis exécution sans corps, cible comparée par ca-server avant toute consommation), les quatre actions de registre qu'oe_actions exécute déjà :

Route	Action	Cible contrôlée
POST /api/v1/operators	invite_operator	le type seulement (l'opérateur n'existe pas encore)
POST /api/v1/credentials/{credential_id}/confirm	confirm_key	credential_id
POST /api/v1/credentials/{credential_id}/revoke	revoke_key	credential_id
POST /api/v1/operators/{name}/role	set_role	operator (par son nom)

• oe_actions::Expect gagne credential_id et operator ; le contrôle de cible devient générique : la cible du corps figé est comparée au champ d'attente correspondant, tout autre champ d'attente renseigné est refusé.
• Jeton d'invitation : rendu une seule fois dans result.invite_token de la réponse d'exécution, jamais journalisé (ni par ca-server ni par la console — vérifié par test).
• Rôle admin (création, élévation, changement du rôle d'un administrateur) : deux administrateurs par la politique de ca-server ; la première signature rend AWAITING_QUORUM, la seconde passe par /api/v1/quorum/{id}/sign, dont frozen_at_this_stage/relayed_at_this_stage acceptent désormais les actions de registre et qui joint la cible correspondante.
• Nouvelles routes isolées dans bin/ra-console/src/registry_routes.rs ; http.rs ne change que le routeur, le filtre d'actions, la cible des co-signatures et quelques pub(crate).
• docs/RA-CONSOLE.md à jour.

Décisions à valider

• Confirmation d'une clé : le §5 prévoit POST /api/v1/operators/onboarding/{token}/confirm, mais l'action signée est ConfirmKey { credential_id, key_fingerprint } et le jeton d'invitation est déjà consommé à ce stade (et ne doit pas repasser dans une URL). Route retenue : POST /api/v1/credentials/{credential_id}/confirm, cohérente avec la révocation de clé.
• Changement de rôle : le §5 prévoit /operators/{id}/role ; le corps signé désigne l'opérateur par son nom (SetRole { operator }). Route retenue : /operators/{name}/role, pour que la cible de la route soit exactement celle du corps figé.
• Invitation : aucune cible dans la route (seul le type est contrôlé) : une assertion d'invitation ne peut servir qu'à l'invitation figée pour laquelle elle a été émise, mais la route ne nomme pas l'invité.
• Le filtre d'actions de la console (relayed_at_this_stage) couvre maintenant toute l'énumération fermée d'oe_actions ; une action ajoutée plus tard ne sera relayée qu'une fois nommée.

Limites

• Pas de liste des clés en attente de confirmation côté console (l'empreinte est transmise hors bande par l'invité, §10) ; pas de libre-service (ajout/retrait de ses propres clés).

Vérifications

• bin/ra-console/tests/action_challenge.rs, contre le vrai service d'actions de ca-server et PostgreSQL : invitation → enregistrement par le relais existant (clé en attente) → confirmation par l'admin → connexion de l'invitée ; jeton absent du journal de la console ; révocation de clé où les deux clés appartiennent au même opérateur (seul credential_id distingue) ; changement de rôle où l'action et le rôle sont identiques (seul l'opérateur distingue) ; élévation admin à deux (AWAITING_QUORUM puis co-signature). Tests unitaires d'Expect étendus.
• Mutation (5 mutants, tous tués) : comparaison de credential_id neutralisée ; comparaison d'operator neutralisée ; jeton ajouté au journal de relais ; validation de forme de l'identifiant de clé retirée ; cible de l'opérateur non jointe à la co-signature.
• cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1), cargo test --workspace avec PostgreSQL, cargo audit --ignore RUSTSEC-2023-0071 : verts.

Revue humaine obligatoire

Voir PROVENANCE.md. Chaque case est cochée par le
contributeur humain qui valide la PR, après l'avoir fait lui-même.

• Revue d'architecture validée par l'humain
• Code relu et tests unitaires/intégration vérifiés localement
• Absence de dépendances tierces incompatibles avec la double licence EUPL-1.2 / AGPL-3.0 (make licenses)
• Validation de l'apport intellectuel et de la paternité humaine sur la modification

Assistance par IA

• Cette PR a été produite avec l'assistance de Claude Code : les commits concernés portent la remorque Co-authored-by: Claude <noreply@anthropic.com>, auteur et committer restent humains, et scripts/provenance.py archive a été lancé
• Cette PR a été écrite sans assistance par IA