vault: a lock that lets go, and seals that say what they broke

The idle timeout was checked only when the key was next asked for, so a
vault nobody touched kept its key in memory indefinitely while status
reported it locked. A ticker now drops the key once it is idle, and
status() expires it too. Vault passwords are Zeroizing from the request
body to Argon2.

Re-sealing a file rewrote links with a case-sensitive replace, and only
in documents linked through node_media. Links are now matched by regex,
whatever their case, in every document and card body that names the id.
A folder re-seal carries on past a file that fails and reports how many
failed. Two re-seals of one file no longer both commit.

:share reports how many sealed files the document embeds, since a share
link never serves them, and :encrypt reports how many shared documents
embed what it just sealed. Vault status counts sealed files, so :export!
asks for the password first rather than navigating into a 423 page. A
sealed embed that fails to load while the vault is shut becomes a button
that unlocks it and puts the embed back.

README.md

@@ -209,7 +209,8 @@ and close it, `:passwd` changes the password. A sealed file carries a lock in
 the list, and the bar says `vault open` while it is.
 
 The vault closes itself after `WORKSPACE_VAULT_IDLE_MIN` minutes of nobody
-using it (15 by default), on logout, and whenever the server restarts. While
+using it (15 by default) — the key is dropped from memory then, not merely
+refused on the next look — on logout, and whenever the server restarts. While
 it is closed a sealed file shows as sealed and nothing more; a share link never
 serves one, open or not; and `:export!` refuses until it is open, because an
 archive meant to be read without this application has to hold the files
@@ -222,6 +223,18 @@ id, and its bytes are AES-256-GCM in 64 KiB records, the last one marked as
 last — so a file that is swapped, cut short or tampered with refuses to open.
 Changing the password re-seals the master key and rewrites no file.
 
+A sealed file is served with `Cache-Control: no-store`, so the browser keeps
+no copy of what it showed once the vault shuts. A sealed image in a document
+shows as a button while the vault is shut, which asks for the password and
+puts the image back. `:share` says how many sealed files a document holds,
+since its readers will not see them, and `:encrypt` says how many shared
+documents just lost a picture to the vault. `:encrypt` on a folder seals
+what it can and counts what it could not, rather than stopping at the first.
+
+Only the bytes are sealed. A sealed file's name, and the names and text of
+the documents around it, stay readable in `diary.db` — and in the mirror of
+it — like everything else outside the vault.
+
 **There is no recovery.** Forget the vault password and every sealed file is
 gone — from the server and from every backup — which is exactly what makes it
 worth having. The password is not in `.env`, not in `diary.db`, and not in the