test(auth): cover notification and user router audiences

docs/route-access-matrix.md

@@ -168,6 +168,29 @@ Reasoning:
 - the calendar catalog is currently consumed in the web app only by the admin vacation editor, so broad authenticated reads expose internal configuration without a product need
 - narrowing just the catalog reads keeps the hardening slice small while avoiding regressions in shared holiday-resolution helpers used by vacation, timeline, and assistant flows
 
+### `packages/api/src/router/notification.ts`
+
+- `list`, `unreadCount`, `markRead`, task detail/status routes, reminder routes, and `delete`: `self-service`
+- `create`, `createBroadcast`, `listBroadcasts`, `getBroadcastById`, `createTask`, `assignTask`: `manager-write`
+
+Reasoning:
+
+- the self-service surface is already constrained to the caller's own notifications, reminders, tasks, or assignee visibility
+- broadcast and task-assignment flows can affect other users and organization-wide messaging, so they must stay on explicit manager-or-admin procedures
+
+### `packages/api/src/router/user.ts`
+
+- `me`, dashboard layout/preferences, favorites, MFA setup/status: `self-service`
+- `listAssignable`: `manager-write`
+- `list`, `activeCount`, create/update role and permissions, resource linking, `getEffectivePermissions`, `disableTotp`: `admin-only`
+- `verifyTotp`: `public` for the login flow
+
+Reasoning:
+
+- self-service user routes only expose or mutate the authenticated account's own preferences and MFA state
+- `listAssignable` is an operational lookup for delegation and assignment flows, which fits manager and admin audiences
+- user administration and effective-permission inspection expose high-sensitivity identity and authorization state and therefore should remain admin-only
+
 ## Assistant Parity Rule
 
 - assistant tool visibility must never widen the audience of the backing router