feat(mobile): recette terrain iPhone 15 Pro — 7/7 validés (ADR-005)

Expo Go (App Store) bloqué par le retard d'approbation Apple (SDK 54
contre notre SDK 57) — décision : builds natifs locaux (Xcode/Android
Studio, signature Apple ID personnel gratuite) pour la vraie recette
terrain, Expo Go conservé pour l'aperçu sans installation ailleurs.

- ADR-005 : deux canaux de distribution, managed workflow conservé.
- apps/mobile/.env : EXPO_PUBLIC_USE_RN_FETCH=1 — fix permanent d'un
  bug SDK 57 (fetch global expo/fetch incompatible avec l'upload
  multipart natif {uri,name,type}, classé à tort « réseau
  indisponible » par notre propre gestion d'erreur).
- package.json/app.json : scripts ios/android pointés sur les builds
  natifs (expo run:*) plutôt que expo start (Expo Go), identifiants
  de bundle générés par le prebuild.
- Recette iOS (iPhone 15 Pro physique) : connexion démo, scan caméra
  réel (résolution locale + rejet QR étranger), vrai mode avion (D1),
  conflit de version tranché par l'humain avec photo réellement
  téléversée (D2/D5), persistance de la file à travers fermeture et
  reconstruction de l'app, suggestions R5 au vrai modèle, purge de
  sécurité au changement de compte (ADR-003) — 7/7 validés, la
  validation terrain due depuis release/r4 est levée pour iOS.
- Android : build natif sur émulateur, passage santé complet
  (connexion, navigation, écran Scanner, résolution de référence).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/journal/journal.md

@@ -4,6 +4,53 @@ Trace chronologique des sessions (la plus récente en premier). Le **playbook**
 
 ---
 
+## 2026-07-19 — Pr. Daaif (+ Claude) — Recette terrain mobile sur iPhone 15 Pro : les 7 points validés (ADR-005)
+
+**Actions**
+
+- **La recette « mode avion » due depuis `release/r4`** a enfin pu se jouer sur un vrai appareil (iPhone 15 Pro
+  du référent). Premier obstacle immédiat : Expo Go (App Store, dernière version) refuse le projet — « supported
+  SDK 54 » contre notre SDK 57, retard d'approbation Apple structurel, hors de notre contrôle. **Décision du
+  référent** : construire des builds natifs locaux (Xcode/Android Studio, signature gratuite via Apple ID
+  personnel) pour la vraie recette terrain, tout en conservant Expo Go comme canal léger pour un aperçu sans
+  installation ailleurs — actée dans **ADR-005**.
+- **Cinq obstacles techniques réels** rencontrés et corrigés en route (détaillés dans ADR-005) : ciblage par UDID
+  plutôt que nom d'appareil (apostrophe) ; ne jamais contourner `expo run:ios` par un `xcodebuild` manuel (a
+  produit un crash `dyld: Library not loaded React.framework`) ; **incompatibilité des modules Expo/RN
+  précompilés (SDK 56/57) avec la liaison statique du projet** — fix `EXPO_USE_PRECOMPILED_MODULES=0` +
+  `RCT_USE_PREBUILT_RNCORE=0` ; **`fetch` global (`expo/fetch`) incompatible avec l'upload multipart natif**
+  (`Unsupported FormDataPart implementation`, classé à tort « réseau indisponible » par notre propre gestion
+  d'erreur) — fix permanent `EXPO_PUBLIC_USE_RN_FETCH=1` committé dans `apps/mobile/.env` ; découverte réseau du
+  dev client peu fiable sur ce Wi-Fi (IP du Mac changée 4 fois, reprises via `expo run:ios --device <udid>` qui
+  transmet l'adresse de Metro par deep link plutôt que par découverte automatique).
+- **Recette terrain iOS — 7/7 points validés sur iPhone physique** : (1) connexion démo ; (2) scan caméra réel —
+  résolution locale d'une étiquette réelle (D4) + rejet propre d'un QR étranger ; (3) vrai mode avion (D1) — file
+  d'écriture visible ; (4) verrou optimiste (D2) — conflit provoqué en modifiant l'OT côté serveur pendant la
+  coupure, écran Synchro affichant le conflit, tranché par l'humain, OT clos avec bilan complet et **photo
+  réellement téléversée** (885 Ko, compression D5 confirmée) ; (5) persistance — saisie en file survivant à une
+  fermeture complète + reconstruction de l'app, resynchronisée au retour réseau (limite documentée : un build dev
+  client ne peut PAS démarrer à froid hors-ligne, aucun bundle embarqué — un vrai test « cold start offline »
+  demanderait un build Release, hors périmètre aujourd'hui) ; (6) suggestions IA R5 au vrai modèle sur le
+  téléphone, chips appliqués pré-remplissant les sélecteurs ; (7) sécurité ADR-003 — déconnexion (appui long,
+  purement locale) puis bascule de compte démo, file et cache vides, aucune fuite entre comptes.
+- **Android** : build natif installé sur l'émulateur (`Pixel_3a_API_34`, Android Studio déjà en place) ; passage
+  santé complet — connexion démo, navigation Ma journée → fiche appareil (résolution de référence manuelle,
+  équivalent du scan sans caméra d'émulateur, confirmée fonctionnelle), écran Scanner sans plantage.
+
+**Décisions**
+
+- ADR-005 actée : deux canaux de distribution mobile (builds natifs pour la vraie recette, Expo Go pour l'aperçu
+  sans installation), managed workflow conservé (`ios/`/`android/` jamais committés).
+- La validation terrain due depuis `release/r4` est **levée pour iOS**. La recette sur **appareil Android
+  physique** (vrai mode avion, vraie caméra) reste un reste, faute d'appareil disponible aujourd'hui — même
+  situation qu'iOS avant cette session.
+
+**Prochaine étape** : recette Android sur appareil physique quand disponible ; redéploiement Dokploy
+(`release/r3` puis r5 avec `AI_SERVICE_TOKEN`) ; calibrage `AI_SEUIL_*` sur corpus SPELEV réel ; secret
+`DOKPLOY_WEBHOOK_URL`.
+
+---
+
 ## 2026-07-17 — Pr. Daaif (+ Claude) — 🏁 R5 CLOSE : tag `release/r5`
 
 **Actions**