Take the master key from KEEPORG_MASTER_KEY_FILE

Why: the usual way to hand a secret to a container is to mount it as a file
and name the path in the environment. Compose, swarm and Kubernetes all do
it that way, and it keeps the key out of the process environment and off any
disk the container can write.

What: the master key is now looked for in KEEPORG_MASTER_KEY, then
KEEPORG_MASTER_KEY_FILE, then the configured master_key_file. A secret file
may hold base64, with or without padding or a trailing newline, or exactly
32 raw bytes, because secret stores produce both.

Only the configured path is ever created, which is what keeps a plain
package install working with no setup. The two environment variables name a
key something else owns, so a missing one is reported and vault creation
refused. Minting a replacement there would be worse than failing: it opens
none of the existing vaults, and the mistake would otherwise surface one
failed merge at a time.

The compose example now provisions the key as a real secret rather than an
environment variable, and the Dockerfile and README show the same. Neither
names a version any more, so they stop drifting as the server is bumped.

Proved: unit tests for every source and precedence, all four accepted
encodings, and that a missing secret writes nothing anywhere. In real
containers: a podman secret carrying base64 survives a stop and start with
"1 vault keys available for merging" and merges a stale push afterwards; a
secret holding 32 raw bytes creates a vault; and a secret that failed to
mount is named in the startup log, with vault creation answering with the
three places a key may come from.

docs/HANDOVER.md

@@ -234,11 +234,21 @@ Three different things are encrypted here, and they are worth keeping apart:
    returned by the API, never logged, and never leaves the process.
 3. **Account passwords.** Not stored at all; only PBKDF2-SHA256 verifiers.
 
-The master key comes from `KEEPORG_MASTER_KEY` (base64) or from
-`master_key_file`, which defaults to `/etc/keeporg/master.key` and is created
-with mode 0600 on first start. Without it the server still runs and still
-serves every key-less strategy; only vault creation and merging are refused,
-with a line in the log saying so.
+The master key is looked for in three places, in order:
+
+| Source | Shape | Created if absent |
+| --- | --- | --- |
+| `$KEEPORG_MASTER_KEY` | base64 | no |
+| `$KEEPORG_MASTER_KEY_FILE` | a path to a provisioned secret: base64, or 32 raw bytes | no |
+| `master_key_file` / `-master-key-file`, default `/etc/keeporg/master.key` | base64 | yes, mode 0600 |
+
+Only the configured path is ever created, which is what makes a plain
+package install work with no setup. The two environment variables name a key
+that something else owns, so a missing one is reported rather than replaced:
+minting a key in its place would open none of the existing vaults. Without
+any of the three the server still runs and still serves every key-less
+strategy; only vault creation and merging are refused, with a line in the
+log saying so.
 
 What this buys and what it does not:
 
@@ -425,9 +435,14 @@ Two directories matter, and the whole point is that they are separate:
 - `/var/lib/keeporg` — state and blobs. Mount a volume.
 - `/etc/keeporg` — `server.json` and, by default, the master key.
 
-**Give the master key somewhere durable**, either `KEEPORG_MASTER_KEY` from
-your secret store, or `-master-key-file` pointing at a mounted secret, or a
-volume on `/etc/keeporg`. A container started with none of those mints a key
+**Give the master key somewhere durable.** The best option is a provisioned
+secret plus `KEEPORG_MASTER_KEY_FILE` naming where it landed, which is the
+convention compose, swarm and Kubernetes all follow:
+`--secret keeporg_master_key -e KEEPORG_MASTER_KEY_FILE=/run/secrets/keeporg_master_key`.
+The key is then neither in the process environment nor on a disk the
+container can write, and the file may hold base64 or 32 raw bytes.
+`KEEPORG_MASTER_KEY` and a volume on `/etc/keeporg` also work. A container
+started with none of those mints a key
 into its own layer and loses it on the next `run`. That is survivable but
 annoying: the vaults still open for their users, and only merging stops. The
 server says so at startup —