Implement CASL Authorization management

[pasc4le]

Summary

Implement proper dashboard authorization using the existing CASL setup already present in the repository (@casl/ability, @casl/react, and the current ability/sidebar files).

The current role model relies on a global user.role. This should be refactored so roles are assigned per recruitment session instead, allowing the same user to have different roles across different sessions.

Supported roles should be:

• guest
• member
• clerk
• admin

The default role should be guest.

Permission Model

Permissions should be progressive:

• guest: can only access their own availability page/table
• member: can access their own availability and the aggregated availability page
• clerk: same as member, plus candidates pages and related actions, but cannot access the users list
• admin: full access to all dashboard pages and actions

Scope

• Add the database/model change required to support recruitment-session-specific roles
• Update auth/session loading so the current user role is resolved for the selected recruitment session
• Replace the current simple role checks with clearer CASL abilities for pages, sidebar links, and actions
• Hide unauthorized sidebar links
• Block unauthorized pages with proper Next.js handling
• Protect server actions and API routes, not just the UI

Suggested Implementation Order

1. Review the current auth, ability, and sidebar implementation already in the repository
2. Add the new recruitment-session membership/role model with Drizzle
3. Update services so the dashboard can resolve the user role for the current recruitment session
4. Refactor CASL abilities to describe access to pages and actions more explicitly
5. Apply authorization to sidebar links, pages, and server actions
6. Manually verify behavior for all four roles

Acceptance Criteria

• Roles are stored per recruitment session, not on the global user table
• Each dashboard page is visible only to allowed roles
• The sidebar only shows links the current role can access
• Unauthorized actions cannot be executed from the server
• guest, member, clerk, and admin follow the permission rules described above