auth: additive roles — a principal keeps every mapped group's access

[selic]

Closes #28.

The problem

resolveOidcRole returned one role: an explicit users.role_id, else the
highest group mapping. That was harmless while roles nested by tier
(viewer ⊂ editor ⊂ admin) — the winner contained the loser. It stops being
harmless the moment roles are incomparable, which is exactly what named tool sets
(#27) introduce: a person in Techs and Billing gets the higher-tier role and
silently loses the other's surface.

The model

A Principal carries every role it holds, and the envelope is their union.
PolicyService.allowsAny evaluates each role on its own grant, default tier and
overrides, so adding a group can only ever widen access.

A per-role deny override closes that role's path, not the others' —
subtracting for everyone remains the global kill switch's job. Both halves are
pinned by tests.

Schema v5

Splitting "the admin chose this" from "this came from a group" needed storage:

• users.role_source marks an explicit override, which still replaces
  group-derived roles (that is what an override is for);
• user_login_roles remembers what the last login's group claims mapped to,
  because the cookie and gateway-JWT paths see no group claims and previously
  leaned on the login path writing role_id.

Upgrade safety: existing non-null role_id rows migrate to
role_source='admin' deliberately — on a live deployment they were either set
from the Users tab or written back unchanged by the login path, so nobody's
access moves on upgrade. db/migrate-v5.test.ts builds a v4-shaped database by
hand and asserts exactly that, plus idempotency on a re-run.

Also in this batch (today's diagnosis session)

• GET /api/me/sessions — my connected clients and whether any holds the
  notification stream, rendered next to Apply now on /me. With no stream
  the gateway cannot push list_changed at all, which is precisely when the
  button is the only cure; better shown than explained.
• The /me hint now spells out the whole model: a switch bites immediately, the
  list is fetched at connect time, change first then Apply — and if a client
  still disagrees it is caching above the protocol (new chat, or reconnect the
  connector).
• [mcp] logging of tools/list size and tools/call decisions — names and
  verdicts only, never arguments. "Did the request even reach the gateway?"
  cost an afternoon today; now it is one grep.
• gw_status reported the MODE in its version field, so it claimed to be
  running version "integrated". Both fields now, with a test.
• /api/users reports loginRoles and effectiveRoles; /me shows every role.

Tests

domain/additive-roles.test.ts — two deliberately incomparable roles (techs:
tickets, billing: invoices): the union keeps both surfaces, takes the most
permissive ceiling per upstream, a none grant in one role doesn't drag the
union down, a per-role deny is escapable through the other role while the kill
switch is not, isAdmin is true if any role is, and the session binding key
covers the whole role set order-independently.

db/migrate-v5.test.ts — the upgrade path above.

db/repo.test.ts — resolveOidcRoles union, unmapped groups ignored, no-groups
fallback to stored login roles, replace-all semantics, override replaces, and
clearing the override falls back to the remembered groups.

npm run build clean, npm test 280 passed, suite run twice.

🤖 Generated with Claude Code