[fix] Align frontend RBAC with the backend permission model

[Aloento]

Changes

• New Event (nav + page): visible only to Creator and above (CanCreate)
• Reviews (nav + page): visible only to Operator and above (CanApprove)
• Edit button: Creators can now edit only their own pending events (currentUserId === Event.Creator)
• Extract button: limited to incident types (IsIncident) instead of all non-maintenance types

New helpers in With.tsx

• CanCreate(roles) — Creator, Operator, Admin
• useCurrentUserId() — returns the JWT sub claim for ownership checks

Verification

• pnpm build passes
• pnpm lint passes

[Aloento]

@ecosquad-autoreview review

[ecosquad-autoreview]

Review of PR #406

The role-gating changes look correct overall: CanCreate (Creator/Operator/Admin) is applied consistently to the New Event nav entries (desktop + mobile) and the NewEvent page, the Reviews nav entry is now gated on CanApprove in both navs, the extract button is restricted to incident types, and the edit button now requires ownership for plain creators. CI checks are green (CodeQL, GitGuardian, check). A few things to verify/clean up:

Warning

1. Ownership check may silently fail — src/Components/Event/EventCard.tsx:61-62

   roles.has(Roles.Creators) && currentUserId === Event.Creator

   currentUserId is the JWT sub (src/Components/Auth/With.tsx:96-98), and Event.Creator comes from event.creator (src/Services/Status.Trans.V2.ts:191, optional string). If the backend stores anything other than the exact JWT sub (e.g. an email address or a different Zitadel ID), the comparison is always false and creators silently lose the Edit button on their own pending events — with no visible error. Please confirm the creator field is populated with the sub claim on create/update; if not, map it at the source rather than comparing here.

2. Client-side only enforcement — src/Components/Event/EventCard.tsx:59-65, src/Pages/NewEvent.tsx:13
   Hiding the Edit/New Event UI restricts only the UI. If the underlying create/update API does not itself enforce creator ownership and role, a user can still call it directly. This PR description doesn't mention a server-side counterpart — please confirm the backend already enforces these same rules.

Suggestion

3. Redundant nested Authorized — src/Components/Layout/MobileMenu.tsx:67-72
   The new Authorized rules={CanCreate} is nested inside a plain <Authorized>, and the parent block already requires authentication. Collapse to a single <Authorized rules={CanCreate}> around the New Event item (keep the outer one only for Reviews/Logout) for consistency with TopNavBar.tsx:43-45.

4. Extract button behavior change — src/Components/Event/EventCard.tsx:53-56
   Switching from Event.Type !== EventType.Maintenance to IsIncident(Event.Type) also removes the Extract button for Operational and Information events, not just Maintenance. The PR description says "limited to incident types instead of all non-maintenance types," so this looks intentional, but double-check that Operational/Information events with >1 region service never needed extraction.

Notes (no action needed)

• NewForm.tsx:35 already limits creators to Maintenance only, which matches the new CanCreate gating — consistent.
• Reviews page (src/Pages/Reviews.tsx:101) was already gated on CanApprove; the nav change just aligns the entry point with it.
• Dependency bumps (vite, typescript-eslint, @types/node) are patch/minor and lockfile is consistent.