TEST: Mentee registration

[nora-weisser]

• POST /api/platform/v1/mentees is anonymous. Request body: MenteeRegistration { mentee, mentorshipType, cycleYear, applications[] }.
• Cycle gating:
  • No open cycle → MentorshipCycleClosedException.
  • Request mentorshipType ≠ open cycle's type → InvalidMentorshipTypeException.
• Mentor existence: every mentorId in applications must exist → MentorNotFoundException (404). Today no ACTIVE-status check is enforced on the selected mentors (see §5 risk).
• Boundary cases on the application list:
  • 0 mentors → rejected by @Size(min = 1).
  • 1, 5 mentors → accepted.
  • 6 mentors → rejected by @Size(max = 5).
  • Duplicate mentorId in the request body → silently dropped before insert.
  • Duplicate priorityOrder (in request or against existing rows) → DuplicatedPriorityException.
• Field validation on the mentee payload: email format, LinkedIn URL format, non-blank first/last name, Slack name format.
• Existing long-term mentee submits for the ad-hoc cycle (and vice versa):
  • ensureMenteeId looks up by email and reuses the existing member.id / mentee.id. No duplicate member or mentee row is created.
  • The 5-cap is per cycle; prior long-term applications do not reduce the ad-hoc quota.
  • Applications from the prior cycle remain untouched; new applications are inserted with the new cycle_id.
  • The MENTEE role is re-provisioned idempotently — no duplicate user_account or user_role row.