Add admin role-based event management and Hamneshini explore/reservation flows

[Aguthcoder]

Motivation

• Introduce an admin role and guard so platform operators can create/manage Hamneshini events while keeping existing user auth intact.
• Provide a graphical admin flow to create rich events (tags, traits, capacity, pricing, dates) and make them immediately available in public Explore.
• Add a production-safe reservation flow to prevent overbooking and to support per-user / payment-status handling.
• Update frontend to support role-aware login, admin UI, Explore listing and a dynamic reservation page that matches the requested UX direction.

Description

• Backend: added a typed role model and role utilities and included role in JWTs by updating UserEntity, AuthService and AuthController, introduced src/modules/common/roles.ts, roles.decorator.ts, and roles.guard.ts for role metadata and enforcement, and improved JwtAuthGuard to accept bearer or cookie access tokens. (Changed: backend/src/database/entities/user.entity.ts, backend/src/modules/auth/auth.service.ts, backend/src/modules/auth/auth.controller.ts, backend/src/modules/common/jwt-auth.guard.ts; Added: backend/src/modules/common/roles.ts, backend/src/modules/common/roles.decorator.ts, backend/src/modules/common/roles.guard.ts.)
• Backend: added admin CRUD surface via a new admin-events module and expanded events/reservation flows: richer CreateEventDto / UpdateEventDto, public filtered & paginated GET /api/events, GET /api/events/:id, and authenticated POST /api/events/reserve using a DB transaction + pessimistic row lock to prevent overbooking and enforce one-reservation-per-user; reused existing EventEntity / EventReservationEntity. (Added: backend/src/modules/admin-events/*, backend/src/modules/events/dto/create-reservation.dto.ts, backend/src/modules/events/dto/update-event.dto.ts; Changed: backend/src/modules/events/events.module.ts, backend/src/modules/events/events.controller.ts, backend/src/modules/events/events.service.ts, backend/src/modules/events/dto/create-event.dto.ts.)
• Frontend: updated API client to surface role-aware login responses and added helpers for new endpoints (/auth/me, /events filters, /events/:id, /admin/events); adjusted login flow to redirect admins to /admin/dashboard; added admin pages and UX (multi-step admin/events/new with live preview), public /explore list with filters and /events/[id] reservation page with capacity progress and reserve CTA; added middleware to block non-admin users from /admin/*. (Changed: frontend/src/lib/api.ts, frontend/src/app/(auth)/login/page.tsx, frontend/src/app/events/page.tsx, frontend/src/middleware.ts; Added: frontend/src/app/admin/dashboard/page.tsx, frontend/src/app/admin/events/new/page.tsx, frontend/src/app/explore/page.tsx, frontend/src/app/events/[id]/page.tsx.)
• Why each change: role/guard files enable decorator-driven RBAC; updating auth issues role to clients and cookies to allow frontend to detect role; admin-events delegates to the shared events service to avoid duplicating business rules; reservation transaction logic ensures atomic reservedCount updates and prevents double-reservation; frontend changes wire new endpoints into existing UI patterns and enforce admin-only client navigation.

Testing

• Ran backend build with cd backend && npm run build, which exercised the new code paths but overall build failed due to pre-existing TypeScript errors in legacy modules (unrelated to the PR) so new backend changes were compiled to the extent possible but global build is blocked by existing repo issues. (result: failed)
• Ran frontend linter with cd frontend && npm run lint, which reported existing unrelated lint errors in demo/test pages; new pages were adjusted to avoid introducing new lint failures but the project still reports pre-existing errors. (result: failed)
• Started Next dev server with cd frontend && npm run dev and attempted a Playwright screenshot of /explore, but the dev server surfaced a pre-existing dynamic-route conflict and the capture failed; server reached startup and validated the new routes before the conflict prevented completion. (result: partial/startup reached, screenshot failed)
• Composed changes were committed and are ready for review; manual API verification (post-deploy) recommended: call POST /api/auth/login to receive accessToken + user.role, call POST /api/admin/events as an admin to create an event, verify it appears in GET /api/events and that POST /api/events/reserve enforces capacity and one-reservation-per-user rules.

---

Codex Task