[iPoower]

Les acquittements et la session de synchronisation disparaissaient à la fermeture ; une réponse perdue après écriture pouvait laisser une sauvegarde réussie impossible à reconnaître. Cette PR renforce le transport Supabase existant et conserve le stockage atomique V3 de #31.

Comportement livré :

• Outbox chiffrée persistante avant envoi ; relecture du même ciphertext à la révision attendue avant acquittement ; reprise idempotente après réponse perdue et rechargement.
• Modifications concurrentes conservées en attente ; première source explicitement choisie, conflits non fusionnés automatiquement, refus d’une tête vide/obsolète ou d’un format/historique futur.
• Session mémorisée chiffrée facultative, phrase toujours nécessaire après fermeture, renouvellement sérialisé et déconnexion explicite ; un onglet non écrivain ne démarre pas l’authentification.
• Restauration atomique, copies de récupération séparées et export vérifié ; distinction entre relecture immédiate et vérification après réouverture.
• Migration SQL proposée, NON appliquée : historique transactionnel de 20 versions, contrôle des révisions, RLS et blocage des utilisateurs anonymes. La table d’historique est en lecture seule pour le client.

Validation complète au SHA exact dd7a090b2c6e1e6df5683aa4060ff039b0097c1a :
https://github.com/iPoower/Reconversion-Control/actions/runs/40091265996
✅ provenance, mobile (chromium), mobile (webkit) : success.
Les logs vérifient le checkout de la tête exacte, puis 20 tests Python de publication/provenance ; 16 cas contrôleur (15 N03 conservés + refus de journal futur), 11 groupes transport/crypto, 6 groupes PostgreSQL WASM/RLS, 12 parcours cloud entre deux profils par navigateur et les 16 contrôles atomiques. Suites existantes pédagogie, dossier, navigation, stockage/onglets, restauration et service worker Chromium conservées et réussies. Les attentes ajoutées aux anciens tests portent sur la fin réelle du Web Lock ; aucune assertion n’est retirée ou affaiblie.

Base inchangée : 2ab4c0f74c74b5ad430e10032ae810708113b3f0. Les 17 fichiers locaux sont identiques aux blobs de la tête. Le workflow de publication Pages et son vérificateur sont inchangés ; aucun droit ni paramètre administratif modifié.

Limites : HTTP/Auth simulés, vraie cryptographie/DOM/Storage et PostgreSQL WASM avec Auth simulée. Aucun Supabase hébergé ni iPhone physique testé. Le projet personnel a été observé INACTIVE en lecture seule ; schéma/RLS/SMTP effectifs non certifiés. Les réglages administratifs de github-pages (iPoower approbateur obligatoire, interdiction de bypass) restent à revérifier avant fusion car cette lecture n’est pas disponible au connecteur. Pas de synchronisation garantie PWA iOS fermée ; reprise après ouverture/déverrouillage. Ni une phrase perdue ni un stockage local définitivement effacé ne peuvent être récupérés sans autre copie exploitable.

Configuration, sécurité et récupération : docs/cloud-sync.md.
GO personnel préparé : docs/GO_FINAL_CLOUD_20261024.md.
Aucune fusion, publication, réactivation Supabase, modification de données réelles ni première sauvegarde personnelle autorisée par cette PR.

Rollback : avant fusion, laisser la PR non fusionnée. Après une éventuelle fusion autorisée, revert ciblé via nouvelle PR et CI, sans supprimer V3, outbox ou historique ; exporter/réconcilier les envois incertains avant un ancien client. Déploiement et opération administrative exigent leurs GO séparés.