Enforce account-active status across the auth lifecycle

active? was only checked at the password step of sign-in. A user disabled
afterwards could (a) still complete the 2FA step and mint a valid session, and
(b) keep using any existing session until natural expiry, because per-request
auth only checked session expiry, not user status.

Three enforcement points:
- Mid-flow guard: verify_totp and webauthn_verify re-check active? before
  start_new_session_for, clearing the pending session and rejecting if disabled.
- Request-time guard: find_session_by_cookie now uses Session.for_active_user,
  so a session whose user is disabled no longer authenticates (authoritative,
  catches any disable path including direct DB changes).
- Immediate cleanup: User#revoke_sessions_when_deactivated destroys a user's
  sessions when status changes away from active, so access is revoked everywhere
  at once rather than on the next request.

Tests cover the mid-flow TOTP rejection, request-time rejection of an existing
session after disable, session destruction on disable, and that unrelated
updates leave sessions intact.

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

app/models/session.rb

@@ -7,6 +7,9 @@ class Session < ApplicationRecord
   # Scopes
   scope :active, -> { where("expires_at > ?", Time.current) }
   scope :expired, -> { where("expires_at <= ?", Time.current) }
+  # Sessions whose owning user is currently active. Used at request time so a
+  # disabled account cannot continue to authenticate with an existing session.
+  scope :for_active_user, -> { joins(:user).where(users: {status: User.statuses[:active]}) }
 
   def expired?
     expires_at.present? && expires_at <= Time.current