bug: Creating a mentor via Admin portal loses gender flag and mentorship availability (long-term / ad-hoc) details

[nora-weisser]

When a mentorship admin creates a new mentor via the admin portal, the gender flag and the mentor's chosen mentorship availability (long-term, ad-hoc, or both) are not captured/persisted. The saved record always reports isWomen: false and an empty menteeSection with no longTerm block and an empty adHoc list — so the mentor cannot be matched in either cycle.

Steps to reproduce

1. Log in to the admin portal as MENTORSHIP_ADMIN.
2. Go to "Create mentor".
3. Fill in all mandatory fields and select one or more mentorship types.
4. Submit.
5. GET the new mentor via the API.
   Expected response

{
  "id": 6,
  "fullName": "Mentor",
  "email": "test@example.com",
  "isWomen": true,
  "menteeSection": {
    "idealMentee": "Eager to learn and ask questions",
    "additional": "Additional information",
    "longTerm": { "numMentee": 2, "hours": 6 },
    "adHoc": [
      { "month": "MAY",  "hours": 4 },
      { "month": "JUNE", "hours": 2 }
    ]
  }
}

Actual response

{
  "id": 6,
  "fullName": "Mentor",
  "email": "test@example.com",
  "isWomen": false,
  "menteeSection": {
    "idealMentee": "Eager to learn and ask questions",
    "additional": "Additional information",
    "adHoc": []
  }
}

Differences vs. expected:

1. isWomen always false — no form control exists to set it.
2. menteeSection.longTerm missing entirely.
3. menteeSection.adHoc always [].

Impact:
High. Every mentor created through the admin portal is created without a usable cycle preference and with the gender flag forced to false. They appear in the public list but are excluded by ?mentorshipTypes=AD_HOC and ?mentorshipTypes=LONG_TERM, so the Apply button on the website never enables and the mentor is effectively unmatchable.

Workaround
None in the admin UI. Records can only be corrected via direct database edits.