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