Let an admin delete a vault, behind their own password

The web interface could create a vault and never remove one, so the only
way to undo a mistake was the CLI. There is now a Delete link on every
vault you administer, leading to a page that says what is about to go —
owner, versions stored, grants pointing at it — and asks for your
account password before it goes.

The gate is re-authentication, not a confirmation checkbox. A session
token is enough to read and write a vault; it should not be enough to
erase every version of one, because a session is what an unlocked
laptop leaves lying around. The one-time code is required too when the
account has one enrolled.

It lives in confirmDeletion, so the rule holds wherever deletion is
reachable: DELETE /api/v1/databases/{id} now takes {password, totp?}
and answers 401 without it, and keeporg db -delete prompts. That is a
breaking change to the endpoint, which is why the server goes to 0.7.0
and the desktop clients to 0.4.0.

An account that signs in only through an identity provider has no
password to type. Rather than lock those deployments out of deleting
anything, they confirm by typing the vault's exact name — the weaker
gate, and deliberately the fallback.

Deleting takes the record, its grants, every stored version and the key
a merge vault left with the server, and tells the watchers over SSE.
Copies already in people's mirror directories stay where they are: the
server stops tracking a vault, it does not reach into anybody's home
directory.

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

docs/HANDOVER.md

@@ -353,6 +353,7 @@ browsing, by design.
 | Page | What it does |
 | --- | --- |
 | `/web/vaults` | the vaults you can reach, the create-a-vault form, your own account password |
+| `/web/vaults/{id}/delete` | what deleting a vault destroys, and the password that confirms it |
 | `/web/groups` | the group tree you can see, and a form to add a group inside one you administer |
 | `/web/groups/{id}` | one group: members and their roles, the vaults it reaches and where that access comes from, grants given and revoked, deletion |
 | `/web/users` | the accounts you may see; for a server administrator, disable, enable, clear the second factor, promote, demote, delete |
@@ -393,6 +394,25 @@ No page carries any JavaScript. Each control is its own small form with the
 CSRF token and one action in it, which is what makes the interface work in a
 locked-down browser and keeps its attack surface down to that token.
 
+**Deleting a vault asks for the password again.** Every other control on
+these pages is undoable or additive; this one erases every stored version of
+a file. A live session is what an unlocked laptop leaves lying around, so the
+confirmation page states what is about to go — owner, versions, grants — and
+takes the administrator's own account password, plus their one-time code when
+they have one. The same rule covers the API and `keeporg db -delete`, because
+it lives in `confirmDeletion` rather than in the page.
+
+An account that signs in only through an identity provider has no password to
+type. Refusing those accounts would mean a deployment where nobody can delete
+anything, so they confirm by typing the vault's exact name. That is a weaker
+gate, and it is deliberately the fallback rather than the rule.
+
+Deleting takes the record, the grants pointing at it, every stored version
+and — for a merge vault — the key the server held. It does not touch the
+copies in people's mirror directories: the server stops tracking the vault, it
+does not reach into anybody's home directory. Clients are told over SSE, so
+they stop expecting the file rather than discovering it at the next save.
+
 Creating a vault is one transaction: the server builds an empty KDBX 4
 database, encrypts it with the password from the form, stores it as version
 1, and — for a merge vault — wraps the password under the master key. If the