Sync the self-hosting stack

CHANGELOG.md

@@ -9,6 +9,43 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.
 
+## 2026-09-25 — A fresh Kubernetes install no longer asks for its own vault key `api 0.114.1`
+
+**On the published Kubernetes stack, creating the first administrator asked for the last characters
+of the vault master key, every time.** That proof exists for one case: an instance whose database has
+gone missing while its key survived, which looks brand new from the outside. A genuine first
+installation is never meant to be asked. On Kubernetes it always was. The minting Job writes
+`VAULT_KEY_CREATED_AT` beside the key it generates, but the api read that date only when the key came
+from a file, and this stack passes the key as an environment variable. The date went unread, the
+key's age was unknown, and an unknown age counts as "cannot prove this instance is new".
+
+**The api now reads `VAULT_KEY_CREATED_AT` wherever the key comes from.** A fresh install whose api
+starts within fifteen minutes of the key being minted is claimed without it. The case the proof
+exists for is unchanged: a `jarvis-generated` Secret that outlives its database still carries its
+old date, and the claim still asks for the key.
+
+**The Job now binds its date to its key**, with a fingerprint in the same value
+(`<date> sha256:<16 hex>`), and on this stack the api counts a date only when it is bound to the key
+in use. The api merges `jarvis-generated` and `jarvis-secrets` name by name, so a key you put in
+`jarvis-secrets` yourself would otherwise meet the date the Job minted for another key; a key
+restored before its database would then read as brand new, and its first administrator would be
+free. A date without the fingerprint, or bound to another key, is ignored, and the claim asks for
+the key as before. To have a first install on the manual path claimed without it, bind the date as
+`01-secret.example.yaml` shows. A date more than five minutes in the future is refused too.
+
+**If you apply the files one by one, move `01-secret-job.yaml` to the same api digest as the rest.**
+A Job on an older image writes a date without the fingerprint, and a first install keeps asking for
+the key. Kustomize and Argo CD already give the Job the api's image, from the one `images:` entry.
+
+**An instance deployed before this version and not installed yet will still ask.** Its
+`jarvis-generated` was minted by an older Job, whose date carries no fingerprint and does not count.
+Give the key's last characters. The key is in `jarvis-secrets` if you set
+`VAULT_MASTER_KEY` there, and in `jarvis-generated` otherwise:
+`kubectl -n <namespace> get secret jarvis-generated -o jsonpath='{.data.VAULT_MASTER_KEY}' | base64 -d`.
+
+**The published Compose stack is not affected.** There the key is a file, and its age was already read
+from it.
+
 ## 2026-09-25 — The licence report counts operators, and the paid plans are Business and MSP `api 0.114.0` `web 0.139.0`
 
 **The licence report sends one more number.** Next to organizations, enabled users, agents and assets,