Refuse login for disabled accounts, and stop leaking which accounts exist

[renemadsen]

Step 3 of #8072 — design: docs/superpowers/specs/2026-09-17-resigned-account-login-refusal-design.md (PR #8073).

Steps 1 and 2 shipped: EformUser.IsActive in Microting.eFormApi.BasePn 10.0.35, and the Users.IsActive column in Microting.EformAngularFrontendBase 10.0.39. Nothing reads the flag yet.

This issue

1. Refuse login when IsActive == false on every surface in this repo:

   • AuthService.AuthenticateUser (REST POST /api/auth/token; the core gRPC service delegates here, so it inherits the check)
   • AuthService.RefreshToken — today it mints a fresh 24h token on nothing more than "the row still exists", so a disabled account could otherwise roll its session forward indefinitely
   • AuthService.GetGoogleAuthenticator — anonymous, and a second credential-verification oracle

2. One identical failure message for unknown account, wrong password and disabled account:

   You have entered an invalid username or password

   Today they are three distinguishable hard-coded English literals, and the unknown-account one echoes the submitted username back:

   Case	Today
   unknown account	User with username <what you typed> not found
   wrong password	Incorrect password.
   disabled	did not exist

   The client toasts body.message verbatim (apiBase.service.ts:257-261), so the login box currently tells any visitor which emails have accounts. The UserNameOrPasswordIncorrect resource key already exists in all 25 .resx files and is already used by GetGoogleAuthenticator — reuse it rather than adding a near-duplicate.

   Brute-force lockout keeps its own distinct message: it is temporary and self-resolving, users need to understand it, and it reveals nothing the generic message hides.

3. Bump Microting.eFormApi.BasePn to 10.0.35 and Microting.EformAngularFrontendBase to 10.0.39.

Deploy note

Program.cs:214 runs Database.Migrate() per tenant at startup, so deploying this applies the IsActive column automatically. Deploy the host before any plugin bumps BasePn: the property maps by convention, so a plugin dragging BasePn ≥ 10.0.35 onto a host without the column makes every query against Users fail.

Not in this issue

• Writing the flag when a worker resigns — step 4, in eform-backendconfiguration-plugin and the time-planning plugin (which also owns a second, parallel login implementation).
• Ending already-issued sessions — Resigned/disabled accounts keep working sessions: nothing revokes a live token #8071.

[renemadsen]

Done — shipped in #8075, merged and deployed to all tenants.

Disabled accounts are refused on all three credential surfaces in this repo (AuthenticateUser, RefreshToken, the anonymous google-auth-key endpoint), and unknown account, wrong password, and lockout now answer with one identical message.

The lockout collapse was not in the original plan: review showed that only an existing, active account can ever reach the lockout state, so a distinct "try again after 10 min" told any anonymous caller that an address had a live account at eleven requests each. The IsActive check also moved to after the password verification, so a disabled account does not answer faster than a wrong password does.

Remaining, tracked separately: #8071 (a live token stays valid up to 24h), #8076 (ForgotPassword still enumerates), #8077 (the gRPC path has no lockout).