`AppTheme.NoActionBar` a bien un parent `DayNight`, mais sans dossier
`res/values-night/` ses `@color/colorPrimaryDark` / `@color/colorBackground`
résolvaient aux valeurs claires même en mode sombre système : la bande de
la barre d'état et la fenêtre pré-WebView (flash de démarrage à froid +
fond du splash) restaient sur la palette « porcelaine » claire pendant que
le téléphone — et le contenu WebView de l'app — passaient en sombre.
- `android/app/src/main/res/values-night/colors.xml` (nouveau) : variantes
sombres de `colorPrimary` / `colorPrimaryDark` / `colorAccent` /
`colorBackground`, calées sur les tokens `--color-*` sombres de
`_theme.scss`. En sombre, la bande de la barre d'état devient le
`--color-background` sombre (`#14181A`), sans raccord avec l'app.
`windowLightStatusBar=false` (icônes claires) reste correct dans les deux
modes. Aucun changement de `styles.xml` : il référence déjà ces noms de
couleur, le parent `DayNight` + `values-night/` fait le reste.
- `index.html` : `<meta name=theme-color>` (light/dark) pour teinter
aussi le chrome du navigateur mobile.
Vérification : impossible sur appareil/émulateur dans ce contexte — le job
CI `build-android` (main uniquement) compilera au moins la ressource. La
synchro live de la barre d'état avec le sélecteur de thème *in-app* (via
`@capacitor/status-bar` + JS) reste un éventuel suivi ; ce correctif règle
le « ne suit pas les réglages système » du rapport.
Closes#104
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
