feat(android): patch the snapshot in place, never rebuild it

Section 4 step 4. TVault reads a subset of the fields, so re-serialising the
vault from what it understood would drop attachment contents, created_at, the
account avatar, tombstones, and whatever the desktop adds next - and the
desktop would adopt that amputated version on its next pull, the merge being
last-write-wins on updated_at. Silent, and final.

So nothing is rebuilt: the received JSON is edited in place and the rest is
handed back untouched. What the phone does not understand travels intact by
construction rather than by vigilance.

A corollary worth naming, because it removes the step the plan feared most:
since the patch applies to the snapshot just pulled, there is no merge to
write. Anything untouched is already the server newest version. The only
possible conflict is another device publishing between our read and our write,
which Gitea refuses on the sha.

The self-check tests what is PRESERVED, not what changes: a field unknown to
TVault, an attachment content_b64, the untouched sibling entry, the
tombstones. It reports "patch keeps what it does not understand" on the device
at every debug launch.

Also confirmed by this log: the write token now survives a restart, so the 304
settings fix holds.

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

pmserverApk.dpr

@@ -14,7 +14,8 @@ uses
   PMA.ScreenGuard in 'android-client\PMA.ScreenGuard.pas',
   PMA.Clipboard in 'android-client\PMA.Clipboard.pas',
   PMA.Theme in 'android-client\PMA.Theme.pas',
-  PMA.WebUI in 'android-client\PMA.WebUI.pas';
+  PMA.WebUI in 'android-client\PMA.WebUI.pas',
+  PMA.VaultPatch in 'android-client\PMA.VaultPatch.pas';
 
 {$R *.res}