feat: add User entity with active / domainManager / name fields

[martinydeAI]

Summary

Add the User Doctrine entity — the application's first persistent
identity — with the minimum set of fields needed by upcoming auth and
authorisation work.

Fields

Field	Type	Purpose
active	bool	Whether the user is enabled.
domainManager	bool	Flag for users with elevated authority within their domain (e.g. a kommune-level admin). Distinct from a global admin role.
name	string	Display name.

The entity will grow (email, credentials, kommune association, …) as
the related issues land — keep this PR focused on the three fields above.

Scope

• App\Entity\User under src/Entity/.
• App\Repository\UserRepository.
• Doctrine migration for the new table.
• Smoke tests (once the PHPUnit setup from Add PHPUnit test suite and CI workflow #31 is in place).
• CHANGELOG.md entry under ## [Unreleased] / Added.

Out of scope

Anything beyond the three fields above and the bare entity scaffolding.

Related issues

• User login #2 — User login (consumes this entity once auth lands).
• User roles and permissions #12 — User roles and permissions (domainManager is the first piece;
  the broader RBAC model is tracked there).
• User profile and account management #13 — User profile and account management (UI for editing these fields).
• Define assistant data model #14 — Define assistant data model (Assistant will likely carry an FK
  to User).
• Add PHPUnit test suite and CI workflow #31 — Add PHPUnit test suite and CI workflow (needed for the tests).
• Decide on backend admin/CRUD tooling (EasyAdmin?) and form conventions #39 — Decide on backend admin/CRUD tooling (affects how User is
  administered).

Acceptance

• App\Entity\User exists with active: bool, domainManager: bool,
  name: string and matching getters/setters.
• App\Repository\UserRepository exists.
• Doctrine migration generated and committed.
• CHANGELOG.md updated under ## [Unreleased] / Added.

[martinydeAI]

Heads-up: ADR 004 (#60, PR #61) supersedes the active boolean
planned here. The new model is a status enum on User
(pending | approved | blocked).

When this issue is implemented the entity should ship with
name, domainManager, and status — not active. See the
"Implication for #45" section of
ADR 004
for context.

[martinydeAI]

Second update from ADR 004: domainManager: bool is also superseded
— by the role ROLE_DOMAIN_MANAGER on the existing User.roles
column. Promote / demote is just toggling the role in the array,
and the manager's scope is derived from the part of their own email
address after the @.

Net effect on this issue: when the User entity here is implemented it
ships with only name on top of the auth fields from #2 / PR #59.
Neither active nor domainManager are introduced. See the
"Domain manager — a role, not a flag" and updated "Implication for
#45" sections of
ADR 004.