Basic nav and menus for admin app

Objective

• Deliver navigation and menus for the admin app so Client Care Dashboard (and related admin areas) have clear entry points from a consistent shell.
• Reuse the existing tools menu pattern—same structural approach as the main app sidebar—so admin feels familiar and engineering does not invent a second nav system.
• Reuse NavUser (the control that switches company / membership via session) so admins with multiple brand memberships can change context the same way they do in tools.

Background

• The main tools experience already has a collapsible left nav in attik-frontend/src/components/navbar/Navbar.tsx: it renders favorites, items from navButtons / footButtons in attik-frontend/src/util/data/navButtons.tsx through Navlink, plus notifications and NavUser at the foot of the rail.
• NavUser (attik-frontend/src/components/navbar/NavUser.tsx) shows the signed-in user; when the user has more than one membership, it exposes a “Switch Company” list that PATCHes session/{sessionToken} with selectedCompany, then reloads—so company context stays aligned with the rest of the app.
• Admin is expected to live on a separate entry (e.g. admin subdomain per Admin Foundation), but auth and session should still align with tools once Better Auth / shared session work lands (ATT-1016). This ticket is the shell and nav, not the full auth migration.
• Until product adds more admin destinations, the menu can start minimal (e.g. links or placeholders for Dashboard) while still matching the existing menu structure and NavUser behavior.

Scope

Frontend

• Implement admin shell navigation by mirroring the existing menu structure: vertical rail, Navlink-style items (icons + labels + optional subnav), and the same permission-gating pattern used for navButtons where admin routes need it.
• Reuse NavUser in the admin layout so company switching and account/session actions behave like tools (multi-company dropdown + single-membership link behavior).
• Define an admin-specific nav config (parallel to navButtons) or shared primitives so Dashboard routes are first-class entries; exact route paths and subdomain layout depend on admin app routing (ATT-1015) and Decision needed for final IA.
• Wire the shell into the admin app entry (folder/routing for admin) once that structure exists; tools layout today uses attik-frontend/src/app/tools/layout.tsx with Navbar—admin should follow the same component patterns without one-off markup.

Backend

• No new backend surface is required for NavUser reuse if session and memberships match tools; if admin uses a different host, cookie/session behavior is covered under shared auth work, not this ticket.

References

• attik-frontend/src/components/navbar/Navbar.tsx
• attik-frontend/src/util/data/navButtons.tsx
• attik-frontend/src/components/navbar/NavUser.tsx
• attik-frontend/src/components/navbar/Navlink.tsx
• attik-frontend/src/app/tools/layout.tsx
• Related: ATT-1015 (admin shell entry), ATT-1016 (shared auth / tokens for admin)