User roles and permissions

[yepzdk]

Define and enforce user roles (e.g. anonymous visitor, authenticated user, contributor/uploader, moderator/admin) and the permissions attached to each.

Scope

• Role model and permission checks across the app (view catalog, view details, upload/share, moderate, manage users).
• Integrate with the authentication from User login #2 (User login).
• Guard the upload/share flow and any moderation actions behind appropriate roles.

Acceptance criteria

• Roles defined and assignable.
• Permissions enforced on protected actions/routes.
• Covered by tests.

Part of the User management milestone. Depends on #2.

---

Design reference

Prototype & design direction: Login & access — #/login

[martinydeAI]

ADR 004 (#60, PR #61) commits to two roles whose definitions live in
this issue's scope:

• ROLE_DOMAIN_MANAGER — capability to manage other users whose
  e-mail domain matches the manager's own. Granted by toggling the
  role on User.roles; promotion / demotion is the only mutation.
• ROLE_ADMIN — site admin. Configured in security.yaml
role_hierarchy to imply ROLE_DOMAIN_MANAGER, so admins can
  manage users in any domain without a separate code path.

The supporting voter (e.g. App\Security\Voter\UserManagementVoter)
combines the role check with an emailDomain(current) === emailDomain(target)
match, short-circuited for ROLE_ADMIN. The user-management screen
in #13 uses the same voter to decide what to show.

Both pieces should be considered in-scope here; if they end up
landing as part of #64 (approval queue) or #13 (user management),
update this issue to point at where the work happened so the RBAC
inventory stays tracked.