Keepalive via refresh-session; GET pings measured insufficient

The endurance test refuted the sliding-window model I committed earlier.
A keepalive doing only GET /api/v3/me succeeded at t+0/30/60/90 and was
still rejected by t+120 — consistent with the session ending ~2h after
LOGIN (t+107), and inconsistent with 2h after the last request, which
would have been t+210.

This is a live-vs-source divergence, not a misreading: both the current
JwtWhitelistAdapter and the legacy Feathers ensureTokenIsWhitelisted
re-set the Valkey TTL on every authenticated request, so the source
reads as a sliding window. The instance does not behave that way.

So the keepalive now calls POST /authentication/refresh-session, the
endpoint behind the UI's "Sitzung verlängern" button, which a separate
100s test showed does hold the reported budget at 7200s. It is the only
non-GET request in the server: no body, touches only our own session,
cannot read or modify user data, and is not exposed as a tool, so no
model-driven call can ever be a POST. It logs the returned budget, which
makes a failing extension visible before the session is lost.

Whether this is sufficient is NOT established. Two mechanisms still fit:
an idle TTL that reads fail to refresh (keepalive works), or an absolute
cap/revocation anchored at login — e.g. the IDP's back-channel logout,
which clears every token for the account rather than one. Added
scripts/session-diagnose.mjs to settle it: it logs the budget every 10
min, so a decaying series indicates the former and an abrupt 401 at
7200s the latter. Docs state the open question rather than asserting a
mechanism.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/API.md

@@ -117,11 +117,12 @@ ids as `{buffer:{type:'Buffer',data:[...]}}` rather than hex strings — a leak
 from the legacy Mongo serialisation. `normalizeObjectId` in `src/render.ts`
 converts them.
 
-**The JWT's `exp` is not the session lifetime.** A server-side whitelist entry
-in Valkey (`jwt:{accountId}:{jti}`) expires after `JWT_TIMEOUT_SECONDS` — 7200 s
-on this instance — and every authenticated request re-sets it. Two hours idle
-and the token is rejected with 29 days still on `exp`. The live values are
-public at `GET /api/v3/config/public`. Full write-up in `docs/AUTH.md`.
+**The JWT's `exp` is not the session lifetime, and the source misleads here.**
+Both the current and legacy whitelist implementations re-set a Valkey TTL on
+every authenticated request, which reads as a sliding window. The live instance
+does not behave that way: a session ends ~2 h after **login**, and successful
+reads in between do not extend it (measured — see `docs/AUTH.md`). This is the
+clearest case in this API of live behaviour diverging from upstream source.
 
 **`GET /api/v3/config/public` is unauthenticated and useful.** 78 keys of
 instance configuration, including the session timeouts and feature flags. Handy