feat: socle BDD (tâche 1.9 Phase 1-2) + moteur APT (tâche 2 SJ-0→3) + WIP capabilities/auth/Rust

Checkpoint multi-chantiers (arbre vert : tsc 0 erreur, 70 tests, build OK).
- tâche 1.9 Phase 1 : schéma socle (machine_state/events/reports/raw_artifacts/
  hardware/metrics + colonnes étendues) + wiring refresh/execute. Migration 0002.
- tâche 1.9 Phase 2 : machine_credentials + machine_host_keys (non destructif,
  dual-read + backfill). Migration 0003. Fix séquence journal de migration.
- tâche 2 : SJ-0 (types étendus rétro-compatibles, réducteur Docker, resolveTemplate),
  SJ-1 (update-analyze enrichi), SJ-2 (apply + diff dpkg + timeout inactivité SSH),
  SJ-3 (reboot vérifié boot_id).
- WIP parallèle inclus : /api/capabilities, auth/apiTokens/apiClients, system metrics,
  scaffold app_rust, ajustements frontend.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

app_rust/system-update-gnome/docs/token-storage.md

@@ -0,0 +1,33 @@
+# Stockage du token API
+
+Objectif : l'application locale ne doit pas stocker le token API en clair dans un fichier de configuration.
+
+État actuel du scaffold :
+
+- `--token` : accepté pour test manuel ponctuel ;
+- `SYSTEM_UPDATE_TOKEN` : accepté pour développement ;
+- trousseau système : prévu, pas encore activé dans `Cargo.toml`.
+
+Identité prévue dans le trousseau :
+
+- service : `system-update` ;
+- compte : `api-token`.
+
+Choix technique à finaliser :
+
+- la documentation actuelle de `keyring` indique que Linux dispose de plusieurs magasins possibles, dont keyutils et Secret Service ;
+- pour une app GNOME, Secret Service est le choix naturel ;
+- l'écosystème `keyring` 4.x sépare davantage les composants de librairie, donc l'ajout Cargo doit être fait après choix précis entre `keyring-core` + store Secret Service ou une version `keyring` 3.x encore centrée librairie.
+
+Références :
+
+- https://docs.rs/keyring/latest/keyring/
+- https://docs.rs/crate/keyring/latest
+- https://github.com/open-source-cooperative/keyring-rs/wiki/Keyring-Core
+
+Règle de sécurité :
+
+- token jamais loggé ;
+- token jamais écrit dans les rapports ;
+- token affiché uniquement sous forme de préfixe côté backend ;
+- révocation possible côté backend via `api_clients.revoked_at`.