fix: scope mentors page default view to the open cycle's type (#304)

[yingliu-data]

Summary

Fixes #304 — the public mentors page showed mentors who don't belong to the currently open cycle (e.g. a long-term-only mentor, or a mentor with the wrong month's availability, during an Ad-Hoc cycle).

The page loaded the unscoped default list: selectedMentorshipType defaulted to '' and the fetch only sent mentorshipTypes when present in the URL, so the initial request had no type filter and the backend returned all active mentors. The backend already scopes correctly by type and month when the filter is passed, and already returns the open cycle in the response:

"openCycle": { "mentorshipType": "Ad-Hoc", "active": true }

This change uses that: on first load, when the user hasn't explicitly chosen a type, it defaults the mentorship-type filter to openCycle.mentorshipType, which triggers the backend's existing type + month scoping. Applied once via a ref so an explicit "All" selection is preserved.

Only the client can make this decision, since both "default view" and "user chose All" send no mentorshipTypes param — hence a frontend fix rather than a backend default.

Testing

Verified locally end-to-end against the running backend:

• Ad-Hoc cycle (July): default view auto-applies ?mentorshipTypes=Ad-Hoc and lists only mentors with July ad-hoc availability; a long-term-only mentor is correctly hidden.
• Long-Term cycle: default view auto-applies ?mentorshipTypes=Long-Term and lists only long-term mentors; an ad-hoc-only mentor is hidden.
• "All" filter still shows every active mentor.
• Selecting a specific type still works.

eslint (0 errors), prettier --check, and tsc --noEmit all pass on the changed file.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[yingliu-data]

it's a flaky/environmental E2E failure, not caused by the #304 change,
request manual merge.