feat(android): Gitea read path verified on device

Against Zaki/pm_sync on Gitea 1.26.1, container uploaded through the web UI:
HTTP 200 in 1079 ms, decrypted, cache written with the sha; the next Sync finds
the same sha and skips the derivation entirely. That was the point of the ETag
on the PHP endpoint and it survives the change of transport.

One log line was lying: it announced If-None-Match, which is never sent to
Gitea - the API does not know that header, and the comparison happens on the
sha after reception. Announcing it sent you looking for a 304 from the server
that will never come. It now says "known sha" on that transport.

The plan records the two frictions met on the way, both already fixed: settings
kept only after a successful decryption (so a wrong password lost the URL and
the token every time), and the launch refresh being silent and using the
password stored with the vault rather than the field.

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

mainApk.pas

@@ -784,7 +784,13 @@ begin
       try
       try
         Log('GET ' + AUrl);
-        if FETag <> '' then Log('  If-None-Match: ' + FETag);
+        // NOMMER CE QUI EST REELLEMENT ENVOYE. Sur Gitea aucun If-None-Match ne
+        // part - l'API ne le connait pas, et la comparaison se fait sur le sha
+        // apres reception. Annoncer l'en-tete faisait chercher un 304 du serveur
+        // qui ne viendra jamais.
+        if FETag <> '' then
+          if LClient.IsGitea then Log('  known sha: ' + FETag)
+          else Log('  If-None-Match: ' + FETag);
         LSw := TStopwatch.StartNew;
         LRes := LClient.Fetch(FETag);
         LSw.Stop;