[GH-P0] Coffre de secrets (AES-256-GCM) & schéma GitHub App

[bobdivx]

[GH-P0] Coffre de secrets & schéma

Plan : devforge-plan-github-app.md, phase P0 uniquement. Aucun changement de route ni d'UI.

Checklist d'acceptation

• P0-01 apps/server/src/secret_box.rs : AES-256-GCM, clé maître DEVFORGE_SECRET_KEY (32 octets base64), sinon $DEVFORGE_DATA_DIR/secret.key généré en 0600 (create_new). Format v1:<nonce_b64>:<ct_b64>. SecretBox::seal(&[u8]) -> String, open(&str) -> Result<Zeroizing<Vec<u8>>>, plus les helpers globaux seal/open/open_compat/seal_compat. Redacted<T> (Debug/Display = ***, règle globale 4).
• P0-02 deps : aes-gcm, rand, zeroize, jsonwebtoken, hmac, subtle (sha2 conservé). jsonwebtoken/hmac/subtle sont déclarés pour P2/P3 et ne sont pas encore utilisés.
• P0-03 db::migrate_github_app : github_app, github_installations, github_installation_repos, github_webhook_deliveries, github_manifest_states, pr_previews (TIMESTAMPTZ) + colonnes projects.{github_installation_id, github_repo_id, pr_previews_enabled, legacy_webhook_id} (ALTER dont l'échec est toléré).
• P0-04 PAT scellés au repos : migration qui scelle user_settings.github_token et instance_settings.github_token encore en clair ; lecture rétro-compatible (pas de préfixe v1: = clair) dans user_prefs::github_token, state::resolve_github_client, routes.rs, dev_env.rs ; écriture scellée dans set_github_token et configure_github.

Tests

• secret_box_tests.rs : aller-retour, nonce différent à chaque seal, altération d'un octet ⇒ Decrypt, mauvaise clé ⇒ Decrypt, fichier clé en 0600 puis réutilisé, priorité à la variable d'env, clé ≠ 32 octets refusée, Redacted masqué.
• github_app_migration_idempotent_and_pat_sealed (Postgres) : migrate lancé 3 fois sans erreur, PAT en clair ⇒ v1: puis relu en clair, nouvelle écriture scellée, 4 colonnes projet présentes, private_key_enc scellé ne contient pas BEGIN RSA.
• Local : cargo test --workspace ⇒ 593 passés, 0 échec. Clippy : aucun avertissement dans les fichiers modifiés. cargo clippy --workspace -- -D warnings échoue déjà sur main (crates deploy/github/detect/mcp, problème antérieur, hors périmètre).

Risques / décisions

• Si la clé ne peut pas être chargée (data dir non inscriptible, pas d'env), l'instance démarre quand même : une erreur est journalisée, les PAT restent en clair et la migration ne touche à rien.
• Perdre la clé = perdre les PAT scellés (il faudra les ressaisir). Il faut donc sauvegarder secret.key ou fixer DEVFORGE_SECRET_KEY en prod. Un PAT scellé illisible est lu comme vide, sa valeur brute n'est jamais renvoyée.
• Aucune valeur secrète n'est journalisée (les messages d'erreur ne contiennent que des chemins et des catégories).