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/static/app.js

@@ -749,10 +749,15 @@ async function changePassword() {
 
   await withLoading(btn, t('loading.updating'), async () => {
     try {
-      await call('POST', '/users/me/change-password', {
+      const data = await call('POST', '/users/me/change-password', {
         current_password: currentPassword,
         new_password: newPassword,
       });
+      // The server just invalidated every previously issued token (B-34) —
+      // including the one this very request was authenticated with — and
+      // handed back a fresh one so this tab doesn't get logged out too.
+      token = data.access_token;
+      localStorage.setItem('plm_token', token);
       document.getElementById('settings-current-password').value = '';
       document.getElementById('settings-new-password').value = '';
       document.getElementById('settings-new-password-confirm').value = '';