Fix F-16: revoke old system token before issuing new one

- ui/handlers_accounts.go (handleIssueSystemToken): call
  GetSystemToken before issuing; if one exists, call
  RevokeToken(existing.JTI, "rotated") before TrackToken
  and SetSystemToken for the new token; mirrors the pattern
  in REST handleTokenIssue and gRPC IssueServiceToken
- db/db_test.go: TestSystemTokenRotationRevokesOld verifies
  the full rotation flow: old JTI revoked with reason
  "rotated", new JTI tracked and active, GetSystemToken
  returns the new JTI
- AUDIT.md: mark F-16 as fixed
Security: without this fix an old system token remained valid
  after rotation until its natural expiry, giving a leaked or
  stolen old token extra lifetime. With the revocation the old
  JTI is immediately marked in token_revocation so any validator
  checking revocation status rejects it.

AUDIT.md

@@ -234,7 +234,7 @@ The REST `handleTokenIssue` and gRPC `IssueServiceToken` both revoke the existin
 | No  | F-12 | LOW | No username length/charset validation | Small |
 | No  | F-13 | LOW | No minimum password length enforcement | Small |
 | No  | F-14 | LOW | Passphrase string not zeroed after KDF | Small |
-| No  | F-16 | LOW | UI system token issuance skips old token revocation | Small |
+| Yes | F-16 | LOW | UI system token issuance skips old token revocation | Small |
 | No  | F-15 | INFO | Bearer prefix check inconsistency | Trivial |
 
 ---