access-principals-admin

# Settings access from database principals

Who may open Settings is decided today by a hardcoded list of three email
addresses in `web/src/settingsAccess.ts`. Replace it with access principals
stored in the database, which admins manage from a new Settings → Access page.

- A principal is an email address or a whole email domain, stored normalized
  (trimmed and lowercased, a domain without a leading `@`); there is at most
  one principal per email address and per domain. It has a role, `admin` or
  `member`, and a list of permissions, each `{ "type", "key", "action" }`:
  - `operating_company` with action `view`, keyed by an operating company's
    code;
  - `dashboard` with action `view` or `edit`, keyed by a dashboard's slug;
  - `feature` with action `use`; the only feature so far is `ai_chat`.

  The key `*` means every resource of that type. Admins always hold every
  permission: each type's `*` with each of its actions.
- Permissions are only stored for now. Nothing outside Settings checks them
  yet, and who can sign in or use dashboards, AI chat and company data does
  not change.
- A signed-in person's principal is the one for their exact email address if
  there is one, otherwise the one for their email's domain.
- Only people whose principal has the `admin` role may open the Settings
  pages or use the APIs behind them (integrations and company setup, the
  retention data upload). Everyone else is turned away the way people outside
  the list are today. The three people on today's list must be admins once
  the migrations have run.
- `GET /api/access/me` answers anyone signed in with
  `{ "principal": <their principal> }`, or `{ "principal": null }` when they
  have none. The header shows the Settings gear only to admins.
- Settings → Access (`/settings/access`) lists every principal and lets an
  admin add, edit and remove them; the form for adding one starts with all
  companies, all dashboards (view) and all features. The page works through
  these routes, which only admins may use:
  - `GET /api/access/principals` → `{ "principals": [<principal>, ...] }`
  - `POST /api/access/principals` with
    `{ "kind": "email" | "domain", "value", "role", "permissions" }` → the new
    principal
  - `PATCH /api/access/principals/{id}` with the same body → the updated
    principal
  - `DELETE /api/access/principals/{id}`

  A principal is returned as `{ "id", "kind", "value", "role", "permissions" }`,
  its value normalized. A write with an invalid email address or domain,
  another role or kind, a permission type or action not listed above, or a
  key that names no existing operating company, dashboard or feature gets a
  400 and changes nothing. A second principal for an email address or domain
  that already has one is refused too, and an unknown id gets a 404.

## Environment

PostgreSQL on localhost:5432 and the local database endpoint the app's
driver uses are running when you start, and the dev env files point at the
dev database.