Merge concurrent saves on the server, with vaults created from the web

Why: the point of a sync server is that two people can work at once. Picking
a winner was all this one could do while it could not read a vault.

What, end to end:
- A vault is created at /web or with `keeporg vault -create`: the server
  builds an empty KDBX 4 file, encrypts it with the password from the form,
  and stores it as version 1. An existing database can adopt a stored key
  with `keeporg db -id <id> -store-password`, which is verified against the
  stored file before it is accepted.
- A stale push to a `merge` vault is no longer refused. The server opens the
  stored version and the pushed one in memory, folds them together, and
  stores the re-encrypted result. Clients push as usual and pull what comes
  back. Any failure answers 409 merge_failed and the client keeps its copy
  aside, so a failed merge still loses nothing.
- At rest: vault contents stay KDBX-encrypted as always. A merge vault's
  password is kept AES-256-GCM-wrapped under a master key that lives outside
  the data directory, bound to the vault id, never returned by the API. A
  stolen data directory is ciphertext; a stolen data directory plus the
  master key is not. The server runs without a master key and simply refuses
  to create or merge vaults.

This moves the server inside the trust boundary for vaults it can merge,
which is inherent to merging and is stated plainly in the README, the
handover notes and the web form itself. Key-less strategies are unchanged and
remain the default for a database created without a password.

Proved: two clients editing the same version are merged rather than refused,
the newer edit of one entry wins, a merge failure leaves the stored vault
untouched, `merge` is refused without a stored key, the wrapped key never
appears in state.json or the API, and the web interface rejects a form
without its CSRF token, withholds its cookie over plain http, and only offers
groups the user administers. Checked by hand against the real thing: a vault
created in a browser, edited by keepassxc-cli on two sides from the same
version, merged by the server, and both entries read back out with
keepassxc-cli. make check, make test-race, android lint and both .deb builds
are clean.

android/metadata/cc.tiredsysadmin.android.keeporg.yml

@@ -16,12 +16,15 @@ Description: |-
   Keepass2Android opens them as ordinary files.
 
   Each save is pushed to the server, and changes other people push are applied
-  here. When two people save at once, the database's merge strategy decides
-  the outcome; the losing copy is always kept beside the file so nothing is
+  here. When two people save at once, a merge vault has both edits folded
+  together by the server; on any other setting the database's conflict
+  strategy decides, and the losing copy is kept beside the file so nothing is
   lost silently.
 
-  The app never opens a database and never sees a master password. It moves
-  encrypted bytes and nothing else.
+  The app itself never opens a database and never sees a master password. It
+  moves encrypted bytes and nothing else. Note that merging requires the
+  server to hold that vault's key, which is a choice made per vault when it
+  is created.
 
   Sign in with a password and the server's built-in time-based second factor,
   or approve the device in a browser, which is also how single sign-on works.
@@ -38,7 +41,15 @@ Builds:
       - yes
     output: android/app/build/outputs/apk/release/app-release-unsigned.apk
 
+  - versionName: 0.2.0
+    versionCode: 2
+    commit: v0.2.0-android
+    subdir: android/app
+    gradle:
+      - yes
+    output: android/app/build/outputs/apk/release/app-release-unsigned.apk
+
 AutoUpdateMode: None
 UpdateCheckMode: Tags
-CurrentVersion: 0.1.0
-CurrentVersionCode: 1
+CurrentVersion: 0.2.0
+CurrentVersionCode: 2