fix(android): USE_BIOMETRIC, and never lock the cache behind a door we cannot open

Opening the vault threw java.lang.SecurityException: USE_BIOMETRIC is not in
Delphi default permission list, and CanAuthenticate raises instead of
answering false. So the fault showed up neither at compile time nor at
startup, but on the first unlock - after the cache had already been written
under an auth-protected key.

The permission is the shallow half. The deep half is that SaveVault was
called with a hard-coded True: we asked for a key guarded by a prompt that
could not be shown, producing a file that was unreadable forever. It now
receives BiometricAvailable, evaluated on the main thread before the worker
starts.

BiometricAvailable and AuthenticateThen also swallow what comes up from the
Java layer and map it to boUnavailable. The caller has a path for every
TBioOutcome and none for an exception.

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

android-client/README.md

@@ -213,6 +213,27 @@ Pour que le téléphone voie l'endpoint local :
 adb reverse tcp:8080 tcp:80
 ```
 
+## Le piège de la porte sans clé
+
+`USE_BIOMETRIC` **ne fait pas partie de la liste de permissions par défaut de
+Delphi**. Sans elle, `CanAuthenticate` ne répond pas « pas de biométrie » : il
+lève une `java.lang.SecurityException`. Le défaut ne se voit donc ni à la
+compilation, ni au démarrage, mais à la première tentative d'ouverture — après
+que le cache a déjà été écrit sous une clé protégée par authentification.
+
+Le résultat est le pire cas possible : **un cache fermé derrière une porte que
+l'application ne sait pas ouvrir**. Trois corrections, dont une seule est la
+permission :
+
+1. Les deux `uses-permission` dans le modèle de manifeste.
+2. `BiometricAvailable` et `AuthenticateThen` attrapent ce qui remonte de la
+   couche Java. L'appelant a un chemin pour chaque `TBioOutcome`, il n'en a
+   aucun pour une exception.
+3. **`SaveVault` ne reçoit plus `True` en dur** mais `BiometricAvailable`. On
+   ne demande une clé sous authentification que si l'invite peut réellement
+   s'afficher — sinon le cache serait illisible pour toujours, et la seule
+   sortie serait de l'effacer.
+
 ## Piège de compilation rencontré
 
 Cette installation de Delphi ne produisait **aucun** APK FireMonkey