fix(auth): revoke account scope matches the account UUID only, and rejected API keys still list as active #534

Summary

The revoke scope check matches the account UUID only, while History matches the external account id plus the account name. Separately, API keys rejected by the password_version check can still list as active.

Location (origin/main 496d9d7)

• internal/api/handler_purchases_revoke.go:403 (from fix(api): scope revoke-any to the caller's accounts on executed purchases #491) calls scope.Allows(*record.CloudAccountID, "") with an empty name. History uses allowed.Allows(p.AccountID, nameByID[p.AccountID]) (internal/api/handler_history.go:1015).
• internal/auth/service_apikeys.go:402 rejects a key whose PasswordVersion differs from the user's, but the key stays is_active=true in ListAPIKeysByUser if the revocation scan failed (fix(auth): reject API keys minted before the owner's last password change #492). Cosmetic.

Failure scenario

A scoped user whose allow-list uses account names, or whose row has only an external AccountID, sees the row in History and gets 403 when revoking it.

Suggested fix

Look up the account with lookupCloudAccount and fall back to AccountID. For the key list, mark a key stale when key.PasswordVersion != user.PasswordVersion.

Context

Related: #386, #433.

Acceptance

A user who sees a purchase row in History can revoke it when scope allows, and stale-version keys no longer list as active.