frontend: surface GET /api/v1/users/me in the TopBar user dropdown

[sthanikan2000]

Problem

GET /api/v1/users/me (backend/internal/user/handler.go, ProfileService.GetMe) has no frontend consumer. It returns:

{ "email": "...", "name": "...", "roles": ["OGA Reviewer"] }

The TopBar's UserDropdown (frontend/src/features/user/Auth.tsx) already shows a name and email, but they come entirely from the client-side OIDC ID token (auth.user?.profile, via react-oidc-context) — not from this endpoint. So email/name in the response are redundant with what's already shown. The one thing this endpoint uniquely provides, and that the ID token cannot, is roles: the caller's RBAC-resolved role names, looked up server-side against the persisted UserID (internal/rbac.RoleService.GetRolesForUser). Nothing in the UI currently surfaces which role(s) a signed-in reviewer holds.

Endpoint-level scope authorization for this route (agency:profile:read, #232) has just been added, so it's now enforced but still effectively dead code from the frontend's side.

Deployment note: the IdP only grants scopes the SPA actually requests at /authorize via VITE_IDP_SCOPES — role-permitted is not enough (#232 fixed every other agency:* scope being missing from this list across the repo). agency:profile:read was deliberately left out of that fix since nothing calls this endpoint yet. Once this issue adds that call, add agency:profile:read to VITE_IDP_SCOPES in all of: root .env.example, frontend/.env.example, backend/.env.example, deployments/helm/values-example.yaml, frontend/workload.yaml, start-dev.sh's fallback, docs/deployment-openshift.md, and the code-level fallback + doc line in frontend/src/features/user/oidcUserManager.ts / frontend/README.md — otherwise the token never carries it and this feature 403s for every user regardless of role.

Proposed Solution

• Add frontend/src/features/user/service.ts calling GET /api/v1/users/me, following the existing per-feature service.ts convention (see frontend/src/features/consignment/service.ts — http + API_BASE_URL, attachToken: true).
• Extend UserDropdown to fetch and display the returned roles — simplest placement is a small role badge/line under the email in the existing dropdown panel (frontend/src/components/Layout/TopBar.tsx renders UserDropdown in the top-right of the header).
• Keep name/email sourced from the OIDC token as they are today; only add the roles list from this endpoint.
• Design detail (badge vs. plain text, one role vs. a list, loading/error state) is open — this issue is to scope and implement whichever is simplest, not to lock in a specific visual.

Alternatives

• Decode roles from the ID token directly instead of calling the backend — not viable, since roles are resolved server-side from the persisted user record, not carried as an IdP claim.
• Show roles in a dedicated profile page instead of the TopBar dropdown — more work for the same information; the dropdown is simpler and already the natural "who am I" surface.