fix(server): fail closed when API_SECRET is unset (auto-generated secret + explicit dev opt-out) - #580

…p warning

- register AUTH_NOT_CONFIGURED in the backend error code table so clients of
  a hardened backend see bilingual guidance: retrieve the generated secret
  from the backend logs or data/.api-secret, then enter it as the client
  API Secret;
- show an inline amber warning on the WebDAV/backup "include keys" toggle
  while it is enabled: the backup file contains plaintext keys, keep it
  safe. New includeKeysToggle.warning-backup-file-contains-plaintext-keys
  string added to all 10 locales (parity gate passes).

- resolveApiSecret: env precedence and trimming, dev escape hatch, generated
  file mode 0600 plus startup banner, restart reuse, never overwriting an
  existing or concurrently created .api-secret, and empty-file /
  unwritable-dir / EEXIST-race fallbacks that keep auth on without
  crash-looping;
- resolveEncryptionKey: an existing key is reused (never regenerated) and
  the new backup warning fires only when a key is generated;
- auth middleware: fail-closed AUTH_NOT_CONFIGURED (including missing
  credentials against a server-generated secret), dev-mode pass-through
  with exactly one warning, and unchanged Bearer enforcement for
  operator-set secrets;
- services/config.test.ts sets env before importing config.js so running
  the suite no longer writes key files into server/data.

API_SECRET is no longer "auth disabled when unset": document auto-generation
into data/.api-secret, the ALLOW_INSECURE_NO_AUTH dev escape hatch, an
upgrade note for existing deployments (retrieve the generated secret once
from the backend logs, enter it in the Web UI, optionally pin API_SECRET in
.env), and a recommendation to back up data/.encryption-key. The docker run
example no longer labels a secret-less backend as unauthenticated. EN/ZH
kept in sync.

…idance

The backend proxy 401 handler only recognized body code 'UNAUTHORIZED'
(rejected operator-set API_SECRET). With the auth hardening the middleware
also returns 'AUTH_NOT_CONFIGURED' when the client has not entered the
server-generated secret yet; that response previously fell through to the
GITHUB_TOKEN_INVALID_ERROR sentinel, telling freshly upgraded zero-config
users their GitHub token expired and steering them into a pointless token
reset.

Recognize AUTH_NOT_CONFIGURED in the same proxy-401 branch and throw the
bilingual registry copy via translateBackendError, which points at the
backend API Secret field instead. The UNAUTHORIZED path (operator-set
secret) and the forwarded-upstream-GitHub-401 path are unchanged, as is the
body-read timeout handling.

Adds a regression test in the 401 source-distinction suite: a proxy 401
carrying code AUTH_NOT_CONFIGURED must not surface the GitHub-token
sentinel and must mention the API Secret (true for both zh and en registry
copy).

The standalone-backend "Basic" docker run example was still labeled
"no auth" and the env tables said an unset API_SECRET disables
authentication - contradicting the hardening behavior where the backend
auto-generates a secret into data/.api-secret on first start.

Update both DOCKER.md and DOCKER_zh.md to the README framing: the default
is an auto-generated secret persisted to data/.api-secret, all /api
requests then require it as a Bearer token, retrieval is via container
logs or reading the file, and ALLOW_INSECURE_NO_AUTH=1|true is the
explicit zero-config dev escape hatch (new table row in both docs).

The startup banner told operators the banner was "visible again via
docker compose logs backend", and the auth middleware's English fallback
for AUTH_NOT_CONFIGURED said to retrieve the secret "from the backend
logs or data/.api-secret". Since the secret value is deliberately never
written to logs, logs-based wording sends operators hunting for
something that is not there.

The banner now keeps only the storage path and points at
`docker compose exec backend cat /app/data/.api-secret` (or reading the
file straight from the mounted volume), mentions that the Web UI asks
for the secret once, and offers explicitly setting API_SECRET on the
server as the alternative. The middleware fallback message is aligned
the same way. The ephemeral-secret fallback path (secret only in
memory) is unchanged; its console.error already directs operators to
set API_SECRET.

The config test's banner assertions are updated to pin the new wording
(must reference docker compose exec, must not reference logs).

README (EN/ZH) and DOCKER (EN/ZH) previously said the generated secret
is "printed once to the startup logs" or suggested `docker logs` as a
retrieval path. The secret value is never written to logs by design, so
all guidance now reads the data volume: `docker compose exec backend
cat /app/data/.api-secret` (or reading data/.api-secret directly), with
explicitly setting the API_SECRET environment variable as the fallback
when the file is unavailable.

- the exact 0600 permission assertion on the generated .api-secret now
  runs only off Windows (Windows reports 0o666); on Windows the test
  degrades to asserting the file was created;
- the read-only-directory fallback test is skipped on Windows in
  addition to the existing root skip (no getuid there, and chmod does
  not actually block directory writes, so the scenario cannot be
  reproduced).

The bilingual AUTH_NOT_CONFIGURED guidance told users to retrieve the
generated secret "from the backend logs or data/.api-secret". The secret
value is never written to logs, so the copy now gives the in-container
cat command (docker compose exec backend cat /app/data/.api-secret) or
reading the data/.api-secret file from the data volume directly, and
adds the fallback: if the file is unavailable (e.g. the read-only-volume
ephemeral-secret path), explicitly set the API_SECRET environment
variable on the server.

The warning paragraph was conditionally unmounted when the toggle was
switched off, so screen readers could miss the announcement when it came
back. The live region (role=status / aria-live=polite) is now permanently
mounted and only its content toggles. The warning paragraph carries a
stable per-instance id (useId - the component renders in both the backup
panel and the data-management panel, so a shared literal id would
collide) and is wired to the switch via aria-describedby while visible.