fix(github): make the branch picker usable on repos with 100+ branches

[abdelrhmanehab10]

Summary

• Fixes [Bug]: Branch selector on "Link Repository" is unusable #870 — the branch selector on "Link Repository" silently truncated to GitHub's first 100 (alphabetically-sorted) branches, so on repos with more branches the default main branch could be missing entirely and unselectable.
• Backend listBranches now fetches lazily by page (page/hasMore) instead of truncating, and downstream callers (project creation/validation, deploy prep) were updated for the new paginated contract.
• The branch dropdown (CustomSelect) now actually scrolls — its inner option list previously never resolved a constrained height (a max-h-full percentage-height quirk), so it just silently clipped past the first screenful with no visible scrollbar, independent of the backend truncation bug.
• Scrolling near the bottom of the dropdown now lazily loads the next page (infinite scroll), with a translated "Loading branches..." indicator.
• Added a type-to-filter search input to the branch picker.

Test plan

• API unit tests: apps/api/src/modules/github/github.branches.test.ts covers the new page-based listBranches contract (single page, hasMore on a full page).
• Manually reproduced the original bug and verified the fix live against the public kanbn/kan repo (158 branches, main originally sorted ~53 branches past the old 100-item cutoff):
  • Dropdown now scrolls (clientHeight clamped vs. scrollHeight), confirmed via DOM measurement and screenshots.
  • Scrolling to the bottom fires a real GET /branches?page=2 request and all 158 branches load.
  • Search input correctly filters the loaded branches (e.g. fix/kan → 8 matches).
  • "Loading branches..." indicator appears while a page is in flight.