Suggest GitHub repositories after typing an owner

[naveed949]

Problem

Add Project asks for owner/repository before it can look a GitHub repository up. If you know the owner and not the repository name, you have to leave T3 and find it elsewhere. Submitting owner/ used to call lookup and fail with a generic error. #15969 stops that and asks for the full name. It does not help you find the repository.

Proposal

When the GitHub Add Project field contains an owner followed by /, and optionally the start of a repository name, show that owner's repositories as selectable rows. Choosing a row uses the existing exact lookup and clone path. Show the first 100 repositories, say when the list is cut off, and still accept a typed owner/repository name for anything past that cutoff.

Scope

• GitHub only, in the existing Add Project flow on web/desktop (command palette) and mobile.
• One list operation at the source-control boundary, backed by gh repo list.
• Loading, empty, and failure states, with a retry when the list fails.
• Clone, lookup of a complete name, and other providers stay as they are.

Out of scope: browsing past the first 100, searching all of GitHub, and GitLab, Bitbucket, Azure DevOps, or Forgejo.

Questions

1. Is listing an owner's repositories in Add Project a direction you want?
2. Is a first-100 page, plus typing the full name for the rest, an acceptable cutoff?
3. When the list fails, should the user see the error and a retry, or should exact lookup stay the only path?

Closed #10214 mixed this listing workflow with the validation fix. Julius asked for maintainer approval of this direction and scope before a separate PR. The validation-only replacement is #15969. I will open the listing PR only after that approval is explicit, and I will link it there.

[Ghost-9]

Endorsing this, and supplying the one thing #8654 asked for that the proposal doesn't cover yet: access checks.

Why it matters in practice. I hit exactly the failure this removes — five attempts over ten hours to clone a repository I own, each ending in "The source control operation could not be completed." The cause (a bare name rejected by parseGitHubRepositorySelector) is filed as #17230. Without a list, the only way in is already knowing the exact owner/name, or pasting a URL.

Access checks. "The repositories you can see" is not one set, and the design has to pin each of these down:

• affiliation and visibility must be explicit rather than inherited: owner vs collaborator vs organization_member selects different repositories, and public vs private changes whether a credential is enough.
• Which credential answers the call. The provider talks to the API directly and keeps credentials on the server, and a pinned token/account can differ from whatever gh repo list would use — the list and the subsequent exact lookup have to agree, or selecting a row can fail after the fact.
• Host scoping: with GH_HOST / GitHub Enterprise the viewer and the repository set are per-host, so the list must be scoped to the host the lookup would target, not to github.com.
• Failure states must not degrade to an empty list: a 401/403/404 or a rate limit should say so, since "no repositories" and "couldn't ask" look identical to the user today.

Suggested shape. Request GET /user/repos with explicit affiliation, visibility and per_page=100, follow the Link header for a "show more" step, state when the list is capped, and keep accepting a typed owner/repository beyond the cap — which is what this proposal already says.

Prior art, so the questions don't loop. This direction has been implemented and closed unmerged three times: #8340 (search by name), #10214 (suggest by owner — this discussion is its follow-up), #13228 (search when cloning); the original request #8654 was closed not_planned with a pointer to Ideas. Those PRs answered the open questions here differently, so an explicit maintainer answer to (1)–(3) is what unblocks a PR.