Auth: decide session-timeout policy for the token flow (sliding idle vs. hard max-age)

[mgrossmann]

Part of the Auth redesign epic (#100). Open decision carried over from docs/auth-redesign.md §4 (Token model).

Context

The credentials/ store reaps idle CREDs after SESSION_TIMEOUT (default 30 min, 0 = off). It is a sliding idle timeout — cred->last is refreshed on every cred_find_by_token() hit, so an actively used session never expires; only a genuinely idle one is reaped (cred_reap). The token is deterministic SHA-256(addr,user,pass) and IP-bound; there is no hard max-age.

The mvsMF SPA (mvslovers/mvsmf#161, PR mvslovers/mvsmf#169) now rides this timeout. Its handling is deliberately policy-agnostic / 401-driven: whenever any API call returns 401, the SPA drops the session and returns to the login screen with a "Session expired" notice. So the SPA does not depend on the exact value — but we should still lock the policy on the httpd side.

Questions to decide

1. Is 30 min the value we want in production (specifically on the current :1081 stack)? It is configurable via SESSION_TIMEOUT.
2. Sliding-only vs. a hard max-age? Today an open, active tab stays logged in indefinitely. Do we want an absolute cap (re-auth after N hours regardless of activity)?
3. Do we ever want to expose the TTL/expiry to clients (login response body field or a header) so a client could warn before expiry? Currently not exposed; the SPA relies purely on the 401. Probably out of scope for now, but list it.
4. Token rotation — the deterministic token is not rotated on re-auth (§4). In scope here or a separate hardening item?

Non-goal

No SPA change is required by whatever we decide — the SPA's 401-driven handling already adapts. This issue is to pin the server-side policy and document it.