feat(settings): show which master key is in force on the About tab

[tyler-rich]

Follow-up to #109, branched fresh from dev after that PR's squash-merge.

Why

#109 logs the master key's back-this-up warning once, at generation. An operator who deploys and returns six months later sees nothing. The alternative considered and rejected in that discussion was a per-boot warning that the generated key shares a volume with the database — it would fire on every start of the documented default for most deployments, which is how operators learn to skip startup logs, costing the generation-time warning that actually matters. It also wouldn't work: nobody reads startup logs at month six.

The About tab is where an admin actually looks, so the fact lives there. The existing one-line per-boot source record is unchanged.

What

One row through the path the panel already uses — core/system_info.py → app/api/settings.py → AboutPanel.tsx. No new endpoint, no new setting, no schema change.

• master_key_info() sits alongside host_info() and reports the resolved source (auto_generated / secret_file) and path.

• AboutOut.master_key carries it; the panel renders either

  Auto-generated at /data/app_secret_key — back this up; a Docker secret gives stronger at-rest separation.

  or, for a supplied secret,

  Supplied as a secret file at /run/secrets/app_secret_key — keep your copy backed up.

  Accurate for both sources rather than autogen wording shown unconditionally. Both say to back the key up, because losing it is equally fatal either way; only the separation advice is specific to the generated case.

Constraints it's built to

• No key material, and nothing else new. Source and path only — deliberately not the key version, which is surfaced nowhere else and would be a new disclosure rather than a relocation of an existing fact. Asserted in tests: the response body does not contain the key file's contents, and the object's keys are exactly {source, path}.
• Admin-only, on an endpoint that is not. GET /settings/about is readable by every role (the SPA needs the instance name and health), so the row is populated per request for admins and omitted otherwise — the path is deployment layout a viewer has no need for. Gated on AuthContext.effective_role, not user.role, so an admin's role-capped API token sees exactly what its role sees.
• Never the reason a page fails. master_key_info() reads the cached startup resolution, so it does no filesystem work and cannot generate a key from a request; if no key resolves (a dev instance, where the lifespan warns instead of failing) the row is omitted rather than erroring the whole About response.

Testing

Matches how the other About rows are covered — through the API, since host_info() has no unit test of its own either: both sources, the no-key-material / no-extra-fields assertions, and omission for a viewer, for a role-capped admin token, and when the resolution raises. AboutPanel has no existing frontend test; I did not add one, to stay level with the rows already there — happy to add an RTL test for the two text variants if you'd prefer.

Backend: 634 passed, 5 skipped; ruff + black clean; .env.example in sync. Frontend: ESLint + Prettier clean, 59 tests passed, tsc -b + vite build green.

README § The master key gains a short "checking which key is in force" note; docs/ARCHIVE.md § Deviations has the dated entry recording this as the durable channel chosen over a per-boot log line.