feat(security): reject pending and blocked users at login (#63)

[martinydeAI]

Links to issues

Closes #63.

do-not-merge — depends on PR #86 (#45 + #83).

This branch is stacked on feature/issue-45-user-entity-extension
because the checker reads User::$status, which doesn't exist on
develop yet. Once PR #86 lands, this PR is rebased onto
develop and the do-not-merge label is removed.

Description

Adds App\Security\AccountStatusChecker implementing Symfony
Security's UserCheckerInterface. The pre-auth hook rejects any
User whose status is not Approved:

• Pending → CustomUserMessageAccountStatusException("account.pending")
• Blocked → CustomUserMessageAccountStatusException("account.blocked")
• Approved → no-op (sign-in proceeds normally)

Wired on the main firewall via security.yaml's user_checker:
key. Translations live in a new translations/security.da.yaml
(the security domain that the login template already renders
error messages from via error.messageKey|trans({}, 'security')).

Identity state (this PR) stays orthogonal to authorisation
(PR #87's voter) per ADR 006 — a Blocked user retains the roles
they had before being blocked, they just can't sign in to exercise
them.

Screenshot of the result

n/a — pre-auth hook, no new UI surface. The login form renders the
new localised error inside the existing error block.

Checklist

• My code is covered by test cases.
• My code passes our test (all our tests).
• My code passes our static analysis suite.
• My code passes our continuous integration process.

Verified locally:

• task coding-standards-check — all green.
• task test-coverage — 58 tests, 203 assertions, 100 %
  coverage.

Additional comments or questions

UserCheckerInterface::checkPreAuth() and checkPostAuth() in
Symfony 8 carry an optional ?TokenInterface $token = null second
argument; the override matches that signature. The token slot is
unused here — neither identity check needs it.

The login template (templates/security/login.html.twig)
already renders error.messageKey|trans(error.messageData, 'security')
in its error block, so the new translations slot in without any
template change. That's why the keys had to land in the security
translation domain rather than the project's messages domain.

The two new SecurityControllerTest methods create their pending /
blocked users inside the test via UserManager::createUser(..., status: UserStatus::Pending|Blocked) rather than seeding via
UserFixtures. DAMA's per-test transaction rolls them back so the
baseline Alice + Bob stay untouched.

---

Details - AI specificities

• ADR: docs/adr/006-user-approval-and-account-state.md
  (Draft; lands via docs: add ADR 004 — user registration, approval, and account state #61). Specifically the "Login gating"
  section.
• Stacked on PR feat(user): add name and status fields per ADR 006 (#45, #83) #86. Once that PR merges:
  1. Rebase this branch onto fresh develop.
  2. Remove the do-not-merge label.
  3. Update the body to drop the block reason.
• Out of scope:
  • Any user-facing surface for the "waiting for approval" state —
    that's part of PR 4 (feat: anonymous self-signup with email-domain allow-list #62 registration), which renders the
    check-pending page after a successful signup.
  • Self-service "request re-approval" / "appeal block" flows.
• Test changes pre-approved: the two new methods on
  SecurityControllerTest are additive (no existing assertions
  changed); same approval as PR 1.
• Translation file is new. Symfony auto-loads
  translations/*.<locale>.yaml; no cache clear needed in tests
  (the kernel boots fresh per integration suite via
  tests/bootstrap_integration.php).

[martinyde]

Should we strip roles from blocked users for good measure, or is that bad practice?