Add Entra app-role route authorization for initial ui-staff sections

[nnoce14]

Summary

Implement role-based authorization for top-level ui-staff route sections using Microsoft Entra application roles.

This should remain simple and explicit for the initial proof: route-level access only, not deep action-level permission modeling.

Initial roles in scope

• Staff.TechAdmin
• Staff.Finance
• Staff.ServiceLineOwner
• Staff.CaseManager

Initial route access expectations

• community management section: Staff.CaseManager and Staff.ServiceLineOwner
• user management section: Staff.CaseManager and Staff.ServiceLineOwner
• finance section: Staff.Finance
• tech admin section: Staff.TechAdmin

If Staff.ServiceLineOwner gets its own section, gate it explicitly.

Requirements

• implement centralized route-to-role mapping
• avoid scattering role truth across route packages
• provide unauthorized handling for authenticated users lacking required roles
• keep initial authorization model clear and easy to evolve

Notes

This task should not over-engineer a granular permission framework yet. Top-level route gating is sufficient for the initial staff-portal proof.

Acceptance criteria

• staff top-level routes are protected by Entra app roles
• authenticated users without the required role cannot access protected staff sections
• unauthorized handling is present and user-visible
• route-to-role mapping is centralized rather than duplicated ad hoc across packages