Authorization

Currently any authenticated user can call any route, and the UI shows the same controls to everyone — `is_superuser` is the only check. Different users should be able to do different things, see different things, and only act on records they're entitled to.

Define and enforce an authorization model across the stack:
- Roles (managed in the IdP) decide who can perform which actions.
- Ownership decides who can act on which records.
- The UI reflects what the user is actually allowed to do.

Depends on #287 — role and identity claims must come from the IdP-issued token.

## Expected outcome
- Roles are defined and assigned in the IdP.
- API routes are gated by role and, where relevant, by ownership of the resource.
- Requests that fail either check are rejected.
- The UI hides or disables actions the current user cannot perform.
- Adding a new route or UI control has a consistent way to declare its access rules.