Refactor session_count to accurately reflect sessions, not logins, and add last_session_at timestamp

[cycomachead]

Refactor session tracking to use distinct 4-hour windows instead of login events

This PR decouples session_count from login events so it accurately reflects user sessions rather than authentication actions. A new last_session_at timestamp column is introduced to track when the most recent session window began.

Changes

• migrations.lua: Adds migration 2026-04-06:0 to add a last_session_at (timestamptz, nullable) column to the users table and refreshes the user views.
• app.lua: Adds session tracking logic in the before_filter that runs on every authenticated request — increments session_count and updates last_session_at only if last_session_at is null (first ever session) or 4+ hours have elapsed since the last recorded session.
• controllers/user.lua: Removes session_count increments from both login paths (student first-login and standard login). last_login_at continues to be updated only on actual authentication events.
• db/schema.sql: Adds last_session_at column to the users table definition and both the active_users and deleted_users views.

Architecture Overview

Previously, session_count was incremented directly in the login controller, making it effectively a login counter. The new approach moves session tracking to the before_filter in app.lua, which runs on every authenticated request. By comparing the current time against last_session_at, the system ensures at most one session is counted per 4-hour window, regardless of how many times a user logs in or out during that period.

Field	Behavior After This PR
last_login_at	Updated only when a user authenticates (logs in)
session_count	Incremented at most once per 4-hour window on any authenticated request
last_session_at	Records the timestamp when the current session window began

Reviewer Notes

• The 4-hour window is calculated server-side using a PostgreSQL extract(epoch ...) query to avoid any clock skew issues between application and database.
• Existing session_count values in production will remain as-is; they will continue incrementing under the new (more conservative) logic going forward.

---

Superconductor Ticket Implementation | Guided Review