Access-control inconsistencies (IT dashboard → admin-only pages; schedule/all allows EVALUATOR)

[TusharW4ni]

Part of #285 (Group D — robustness).

Problem

Several access-control inconsistencies between the UI gates and the server: a dashboard advertises pages the role can't open, and a schedule endpoint is broader than the UI implies.

Evidence

• IT_SERVICE dashboard → ADMIN-only pages. The IT dashboard links to /admin/createAccount and /admin/employeeSearch, but those routes are gated ADMIN in types/permissions.ts, and IT_SERVICE does not inherit ADMIN (server/utils/permissions.ts — only ADMIN is a superset). So IT users clicking those links are bounced by middleware/01.permission.global.ts. server/api/search/employees.get.ts is also ADMIN. (Note: the dashboard-consolidation work in Consolidate the 7 role dashboards into one role-aware /dashboard #282 changes how these tiles are gated — reconcile there.)
• schedule/all broader than the UI. server/api/session/schedule/all.get.ts allows [USER_SERVICE, EVALUATOR], but the calendar's "see all sessions" affordance is gated USER_SERVICE || ADMIN. An EVALUATOR could call the endpoint directly and see all sessions (not just their own). EVALUATOR is clinical/PHI-cleared so it's not a leak, but it's inconsistent with the UI intent.

Impact

P2. Dead-end nav for IT users; endpoint/UI access intent drift. Worth settling as the role model is exercised.

Proposed approach

• Decide whether IT_SERVICE should manage employees/accounts; then either grant IT the needed access or remove those tiles from IT (coordinate with Consolidate the 7 role dashboards into one role-aware /dashboard #282's capability-gated tiles).
• Align schedule/all access with intended policy (drop EVALUATOR, or document that evaluators may view all).

Acceptance criteria

• No dashboard links to a page the role cannot open.
• schedule/all access matches a documented policy.