feat(ra-console): double contrôle, co-signature et salle d'attente (étape 4b)

[PhilippeVienne]

Objet

docs/WEBUI.md §8 et §15 étape 4, tranche 4b : deux ca_operateur distincts révoquent ensemble depuis la console. Empilée sur #66 (feat/ra-console-revoke, tête aac4dbc à l'ouverture) → #65 → #64. Ordre de merge : #64, #65, #66, cette PR.

• Co-signature : POST /api/v1/webauthn/challenge accepte {"action_id"} (la console vérifie que l'action existe, n'est pas exécutée et relève des actions proposées), puis POST /api/v1/quorum/{action_id}/sign. oe_actions::Expect gagne action_id, comparé par ca-server avant toute consommation : une co-signature ne compte que pour l'action pour laquelle son challenge a été émis.
• Salle d'attente : GET /api/v1/quorum?state=PENDING — corps figé (à afficher à qui co-signe), empreinte, signatures recueillies/exigées, qui a déjà signé. Lue en lecture seule dans actions et decision_evidence de ca-server (décision de l'utilisateur) : le rôle de la console gagne SELECT sur actions (aucun secret n'y figure : le jeton d'une invitation n'existe que dans le résultat d'exécution). Le test de schéma (operators_schema.rs) est mis à jour en conséquence.
• Écart assumé avec le §8, en plus sûr : pas de tables de collecte côté console, qui ne conserve jamais d'assertion — ca-server enregistre chaque signature au fil de l'eau (decision_evidence, UNIQUE(action_id, operator_id)) et n'exécute qu'au seuil. docs/WEBUI.md §8 dit désormais ce qui est construit.
• docs/RA-CONSOLE.md : salle d'attente, co-signature, note de mise à jour.

Avec #64 à #66, l'étape 4 est complète côté API : révocation d'un certificat à deux opérateurs FIDO2 distincts, sans le CLI.

⚠️ Mise à jour d'un déploiement existant

Rejouer psql -f crates/oe-castore/sql/ra_console_grants.sql (idempotent) : sans le nouveau SELECT sur actions, la salle d'attente et la co-signature répondent 503.

Vérifications

• bin/ra-console/tests/action_challenge.rs (vrai service d'actions de ca-server, vraie CA sur PostgreSQL) : révocation à deux de bout en bout (salle d'attente → co-signature → EXECUTED → certificat révoqué → salle vide → action exécutée plus préparable) ; seconde signature du même opérateur refusée ; co-signature présentée pour une autre action visant le même certificat refusée (action_mismatch, rien consommé), puis acceptée pour la bonne ; action inconnue ou identifiant invalide → 404. Test unitaire d'Expect étendu.
• Mutation (2 mutants, tous tués) : contrôle d'action_id retiré côté ca-server ; action_id non envoyé par la console. Le premier jet du test ne l'aurait pas vu (deux certificats différents : le numéro de série suffisait) — corrigé en faisant porter les deux actions sur le même certificat.
• cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1), cargo test --workspace avec PostgreSQL (droits réels compris : db_guard.rs, operators_schema.rs), 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