Invalidate existing sessions on password change/reset (B-34)

Neither self-service password change nor the admin reset invalidated
already-issued JWTs — a 24h-lifetime token stayed valid regardless, so
a stolen token (or an attacker who already had the old password) kept
working past a password change meant to lock them out. The admin reset
exists precisely for the "account compromised" case and didn't evict
the attacker at all.

Add User.token_version (migration 943dbd74d983), embedded in every JWT
as a "tv" claim and checked against the DB on every request in
get_current_user/get_optional_user; a mismatch reads as session_expired.
Both change-password and the admin reset bump it. change-password hands
back a freshly minted token so the caller's own session keeps working
instead of being logged out by its own request; the admin reset does
not, since that session isn't the one making the call.

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

app/api/routes/admin.py

@@ -215,6 +215,11 @@ async def reset_user_password(
 
     new_password = secrets.token_urlsafe(12)
     user.password_hash = hash_password(new_password)
+    # B-34: this endpoint exists precisely for the "account compromised" case —
+    # without bumping token_version, whoever was already logged in (the
+    # attacker, if that's who prompted the reset) stayed logged in on their
+    # existing token until it naturally expired, unaffected by the reset.
+    user.token_version += 1
     await write_audit_log(session, "admin_password_reset", {"user_id": user_id}, user_id=user_id)
     await session.commit()
     return AdminPasswordResetResponse(username=user.username, new_password=new_password)