#2398 added `require_auth_for_reads` as an opt-in flag that collapses
the dashboard public-read allowlist when set to `true`. In practice
that means an operator who set `api_key = "…"` but forgot the
separate `require_auth_for_reads = true` was still leaking agent
IDs, config, budget, sessions, and pending approvals to any host on
the LAN — because the default was `false` and the flag name wasn't
obvious. The dashboard SPA already handles 401 via its existing
login flow (`setOnUnauthorized` / `getStoredApiKey` / bearer
injection), so the safe default is "close the allowlist whenever
auth is configured", not "closed only when two separate knobs
agree".

Switch `KernelConfig.require_auth_for_reads` from `bool` to
`Option<bool>`:
- `None` (default) → derive from whether any authentication is
  configured: non-empty `api_key`, per-user API keys, or dashboard
  credentials. Setting an `api_key` now auto-collapses the reads
  allowlist, matching operator expectations.
- `Some(true)` → force closed even if auth looks misconfigured.
  Useful for catching an accidental `api_key = ""` redeploy.
- `Some(false)` → explicit escape hatch for deployments fronted by
  an external auth proxy that want the in-tree dashboard to keep
  rendering before the reverse proxy attaches its own credentials.

When the auto-enable path kicks in, log a one-line `info!` so
operators see that reads are now locked. When the operator forces
`require_auth_for_reads = true` but has no auth configured at all,
keep the existing `warn!` so a misconfiguration still surfaces.

All existing public, OAuth, and health endpoints stay reachable
regardless of the resolved value — that list is hard-coded in
`middleware.rs::is_always_public` and unchanged.

Dashboard impact: none. The SPA in `crates/librefang-api/dashboard`
already injects `Authorization: Bearer` from `localStorage` on
every request and intercepts 401 to trigger the login screen, so
flipping the default on for `api_key`-having deployments does not
break rendering — an unauthenticated visitor lands on the login
form, types their key, and resumes.

Migration: operators who explicitly *want* open reads with an
`api_key` set (fronted by reverse-proxy auth, say) must now add
`require_auth_for_reads = false` to `config.toml`. Previously they
didn't need any flag at all.

The original doc claimed Some(true) would force the reads allowlist closed
even when no auth was configured, but the middleware deliberately short-
circuits in that case (middleware.rs:423-426) and falls through to the
unauthenticated local-dev bypass at lines 438-443. That bypass is
intentional — it keeps the flag from silently no-oping when operators use
per-user keys or dashboard credentials instead of a global api_key, which
is explained in the comment above the check.

Rather than ripping out the documented bypass, fix the doc to match
reality: Some(true) logs a boot-time warning when no auth is configured,
but only actually enforces once some form of auth is present. Drop the
stray 'auto' TOML literal from the doc too — Option<bool> never accepted
a string value.

Also simplify the redundant info-log guard in server.rs (the outer match
already narrows to the None branch) and extract the derivation to a
small pure function with unit tests covering all four input combinations
(None + auth, None + no auth, Some(false), Some(true)).