fix(android): protection catches up with the cache, and a dead key gets replaced

After the screen lock was removed and put back, the app stopped asking for the
pattern. Two gaps, both mine.

The cache had been rewritten while the device had no lock, so under the plain
key - and nothing ever moves it back. Protection was decided at write time
only, and a write happens only when a new snapshot arrives; a 304 left the
file in the clear indefinitely. It is now re-sealed on open, where the
plaintext is already in hand.

And the invalidated RSA key was never replaced. Removing a lock, or enrolling
a new fingerprint, permanently invalidates a protected key while its alias
survives. EnsureWrapKey only created the pair when the alias was absent, so it
kept reusing a dead key: every encryption failed and every write fell back to
the plain key, forever. It now deletes and regenerates on a second attempt.

Measured on device: header 1 before, 3 after the first launch.

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

mainApk.pas

@@ -834,6 +834,25 @@ begin
   begin
     FETag := LETag;
     if LPwd <> '' then FSyncPwd := LPwd;
+
+    // LA PROTECTION RATTRAPE LE CACHE. Elle se decidait a l'ecriture seule,
+    // et une ecriture n'arrive qu'avec un instantane nouveau : un cache pose
+    // pendant que l'appareil n'avait pas de verrouillage restait en clair
+    // indefiniment, meme apres en avoir remis un. On le rescelle ici, ou l'on
+    // tient justement le clair.
+    if (not VaultNeedsAuth) and BiometricAvailable then
+    begin
+      try
+        SaveVault(LPlain, LETag, LPwd, True);
+        if VaultNeedsAuth then
+          Log('Cache re-sealed under authentication')
+        else
+          Log('Re-seal refused: ' + LastStoreError);
+      except
+        on E: Exception do Log('Re-seal failed: ' + E.Message);
+      end;
+    end;
+
     try
       AdoptVault(LPlain);
       // Afficher d'abord, synchroniser ensuite : le coffre est a l'ecran, le