[Task][Admin] Invalidate previously issued JWTs after password changes #8176

Context

Reviewed against master commit 1d0133477634f62a5093be10014c96f9f835c645.

Problem and proposed behavior

The current realm verifies JWT signature/expiration and checks the current account status, but does not compare token state against a password-change timestamp or token version. modifyPassword updates the password hash without revoking previously issued tokens.

A production-realm/JWT probe confirmed that an old token remains accepted when the user lookup returns a changed password hash, while disabling the same account causes 401. The probe substituted the persisted-user lookup result; it did not execute the complete password-change endpoint. Static inspection confirms that the password-change service does not update token-revocation state.

Expected: define and implement token invalidation for password change/reset and an administrative revoke action. Account-disable rejection already works and must be retained.

Acceptance criteria:

• A token issued before a successful password change/reset is rejected afterward, and a fresh login works.
• Revocation works across Admin instances without rotating the shared signing key for every user.
• Legacy tokens and rolling upgrades have an explicit compatibility policy.
• Unrelated users' tokens remain valid; account-disable behavior remains covered.

Potential implementation: a persisted per-user token version or credentials-changed timestamp, checked during the existing user lookup. Decide the policy before choosing the representation.

Code references

• java/org/apache/shenyu/admin/shiro/config/ShiroRealm.java
• java/org/apache/shenyu/admin/service/impl/DashboardUserServiceImpl.java
• java/org/apache/shenyu/admin/utils/JwtUtils.java