feat(security): add sliding session token refresh

[dirkwa]

Summary

Active users are silently issued a fresh JWT when their current token is past the midpoint of its lifetime, preventing unnecessary logouts. The rememberMe flag is embedded in the JWT payload so refreshed cookies retain the correct maxAge.

Without this change, once a JWT expires the user must log in again regardless of how recently they used the server. This was reported by users who experienced frequent session loss despite having "Remember Me" enabled.

Changes

• generateJWT() accepts an optional rememberMe parameter and embeds it in the JWT payload
• login() passes the rememberMe flag through to generateJWT()
• http_authorize middleware checks if a valid token is past 50% of its lifetime and silently issues a replacement via Set-Cookie
• JWTPayload interface extended with rememberMe field
• Documentation updated in webapps.md and security-architecture.md

Testing

Tested against a live server with expiration set to 2m:

• Login with rememberMe: true: Token issued with exp claim, cookie set with Max-Age=120
• Request after midpoint (65s): Server responds with fresh Set-Cookie containing a new JWT with updated iat/exp and preserved rememberMe: true. Cookie Max-Age=120 correctly reset
• Login with rememberMe: false: Session cookie (no Max-Age), refresh still works at midpoint, refreshed cookie remains a session cookie
• Old token after expiry: Returns 401 as expected
• Refreshed token after old expires: Returns 200, confirming the new token is independent

Observation

Each refresh response contains duplicate Set-Cookie headers (identical values) because http_authorize runs on two middleware mounts per request. This is harmless — the browser applies them idempotently — but could be cleaned up in a follow-up