fix(auth): check reset link expiry against interactive login timestamp

[silverkszlo]

• Resolves: Notify user before password expiration password_policy#433 (comment)

Summary

The bug

When the password of a user expires and they want to reset it while they have an open session somewhere, the "Forgot password" flow sends them into a loop and never allows them to reset their password: logging in is being refused because the password expired, and the emailed reset link is being refused as expired as well.

How to reproduce

• use an existing user account or create one, e.g. "blume"
• log in to [dev/prod_url] as blume and leave that window open(!)
• expire the password:
  occ user:setting \ blume password_policy pwd_last_updated $(( $(date +%s) - 10*86400 ))
• In another private window go to [dev/prod_url] and log in as blume; you'll see "Password is expired, please use forgot password method to reset".
• go back to login form and click on "Forgot password?" and submit "blume"
• open [local/remote_mail_server] and find the password-reset mail
• click on "Reset your password"
• it takes you to "Could not reset password because the token is expired."

This solution

VerificationToken compared the reset link's creation time against IUser::getLastLogin(). Despite its name that value is a "last seen" timestamp. Session::validateSession() refreshes it on every request of an already authenticated session, so it kept moving past the reset link's creation time while the user did nothing but leave a session open.

This PR records the time of an actual authentication separately (lastInteractiveLogin) and compares against that instead. IUser::getLastLogin() keeps its current meaning, so the administration user list and inactive-account handling are unaffected.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI