feat: implement B.1 — persist login sessions in SQLite with sliding idle timeout

Sessions move from an in-memory map (absolute 12h TTL) to a `sessions`
table (migration 0002), storing only the SHA-256 of the token. Expiry is
now a sliding idle window (PANEL_SESSION_IDLE_DAYS, default 7, no
absolute cap), extended at most once an hour and never by the
monitoring screens' background polling (GET + HX-Request), so a
forgotten open tab doesn't keep a session alive indefinitely. A login
now survives a container restart or redeploy.

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

deploy/.env.example

@@ -16,6 +16,11 @@ RATE_LIMIT_WINDOW_SECONDS=3600
 # Days of send-log history kept before the background sweep deletes rows.
 SEND_LOG_RETENTION_DAYS=90
 
+# Sliding idle timeout for the panel login session, in days. No absolute cap:
+# an admin who keeps coming back stays signed in indefinitely. Polling by the
+# monitoring screens does not count as activity, only navigation/actions do.
+PANEL_SESSION_IDLE_DAYS=7
+
 # Comma-separated CIDRs (bare IPs allowed) of reverse proxies allowed to
 # supply X-Forwarded-For for login/setup rate-limiting. Leave unset unless
 # you know the exact address of your reverse proxy — trusting the wrong

deploy/docker-compose.yml

@@ -39,6 +39,8 @@ services:
       # How long the send log keeps rows before the background sweep deletes
       # them (spec 7.3, 9) — the main driver of /data growth over time.
       SEND_LOG_RETENTION_DAYS: "${SEND_LOG_RETENTION_DAYS:-90}"
+      # Sliding idle timeout for the panel login session, in days (spec 7.6.6).
+      PANEL_SESSION_IDLE_DAYS: "${PANEL_SESSION_IDLE_DAYS:-7}"
     volumes:
       # All persistent state lives under /data (spec 9): SQLite DB, DKIM keys,
       # sasldb2, sender map, setup token. Back this up (panel button or the