sec(auth): POST reset-password answers 403 'account is deactivated' for a live token of a deactivated user, unlike unknown/used/expired tokens #595

Found in the review of PR #592 (closes #421). After #592 the GET status endpoint answers a deactivated user's unexpired token exactly like an unknown token (used/reset). POST /api/auth/reset-password (internal/api/handler_auth.go ~375, internal/auth/service_password.go ~395-399) still returns 403 'account is deactivated' (and consumes the token) for a live unexpired token of a deactivated user, while unknown, used and expired tokens get 400 'invalid or expired reset token'. It requires possession of a live 256-bit token, so exposure is minimal, but GET (used) and POST (403) now disagree for the token holder, and it is the only place the deactivated state is observable.

Acceptance: POST returns the same 400 as an unknown token for a deactivated user (decide whether the token should still be consumed), with a regression test through HandleRequest comparing status and body against an unknown token. Related: #421, #592.