Reconsider gh CLI repo listing in scope resolution

[ewega]

Description

When resolving repos for a GitHub connection scope, the CLI uses gh api to list repos in the org, then presents an interactive multi-select. Two problems:

1. Org mismatch causes silent failure

The org stored in state may not match the actual repos the user wants. In this case the org was ""my-org"" but the repo was in ""eldrick-test-org"":

📦 Resolving repositories... Listing repos in ""my-org"" via gh CLI... ⚠️ No repos found — verify the org name and PAT scopes (read:org) Enter repos (comma-separated): eldrick-test-org/devlake-demo

The user has to manually type the repo anyway.

2. Could overwhelm with large orgs

For organizations with hundreds of repos, even capped at 30, the multi-select list becomes unwieldy. And 30 is an arbitrary cap that may exclude the repos the user actually needs.

Suggestions

Consider whether the gh CLI → interactive multi-select flow adds enough value vs. simpler alternatives:

1. Keep it simple: just prompt for comma-separated repos (or a file via --repos-file). The user always knows their repos.
2. If keeping the picker: use the org from the connection (not state), and allow a search/filter rather than dumping all repos.
3. Pagination: if the picker stays, show repos in pages with a search option rather than a flat capped list.

This is lower priority than the architectural issues (#35, #37) but improves the UX.

References

• cmd/configure_scopes.go — resolveRepos()
• internal/gh/ — ListRepos()