Decide on user registration, approval, and account-state model

[martinydeAI]

The app needs anonymous user registration restricted to email
addresses on an allow-list of approved organisations and an
approval-by-another-user step before a newly created account gets
access. Before we build any of that, we need to decide how account
state is modelled on the User entity.

The space, broadly:

1. Boolean(s) or status enum on the entity — e.g. status: pending | approved | blocked, or active + approved booleans (the
   active half is already in feat: add User entity with active / domainManager / name fields #45).
2. Role-based gating — no roles → no access. Less code, but
   conflicts with Symfony Security's implicit ROLE_USER guarantee
   on the generated User entity, and conflates identity state with
   authorisation.

This issue tracks the architectural decision. The decision is recorded
as an ADR under docs/adr/; the resulting implementation work is
filed as follow-on issues that reference the ADR.

Related

• User roles and permissions #12 — User roles and permissions
• User profile and account management #13 — User profile and account management
• feat: add User entity with active / domainManager / name fields #45 — User entity fields (active, domainManager, name)

Acceptance

• ADR under docs/adr/ recording the decision and rationale.
• Implementation issues opened for the resulting work (self-signup
  with domain allow-list, login gating via UserChecker, approval
  queue UI for domainManager users).
• If the decision diverges from feat: add User entity with active / domainManager / name fields #45's existing field set, update
  or supersede feat: add User entity with active / domainManager / name fields #45 accordingly.

[martinyde]

I like the status: pending | approved | blocked -approach, it makes sense to differentiate between pending and blocked users, and if a Role-based gating approach conflicts with Symfonys usual Security approach thats probably not wise.