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/db/models.py

@@ -21,6 +21,12 @@ class User(Base):
     # Read cache only; must always be written in the same transaction as the
     # utxo_events rows it summarizes. Source of truth is utxo_events.
     cached_balance_sats: Mapped[int] = mapped_column(BigInteger, default=0)
+    # Embedded in every issued JWT (app/auth/security.py) and checked on every
+    # request (app/auth/dependencies.py:get_current_user). Bumped on a
+    # self-service or admin password change so every token issued before that
+    # point stops working immediately, instead of staying valid for up to
+    # jwt_expire_minutes after a compromised account's password is reset (B-34).
+    token_version: Mapped[int] = mapped_column(default=0, server_default="0")
     created_at: Mapped[datetime] = mapped_column(default=utcnow)