Build and release image / build (push) Successful in 1m9s
No change to how the vault is written or recovered. This fixes what the service says when recovery is not possible, and adds a way out that is not "edit files inside a container that will not start". The refusal message was wrong in the case that actually matters. It said the backup "could not be used either" whether the backup was unparseable, empty, or simply absent — and absent is the common one, because a vault that has not completed a single write since v0.1.3 introduced backups has no .bak at all. That wording reads as though a file exists, and sends the operator hunting for it. The message now names which of the three it is, and lists any vault.json.corrupt-* files left by earlier recoveries. DA_VAULT_RESET=1 boots an unreadable vault as empty. It is checked only on the failure path, so it cannot affect a vault that loads, and it quarantines the unreadable file *before* writing the fresh one — the first draft of this logged that the file was preserved while persist would in fact have overwritten it. Refusing by default is still right: booting empty is indistinguishable from a vault emptied on purpose. But a refusal with no supported way forward is not a safety feature, it is a dead end. 149 tests.