fix(github): page installation repositories from 1, and stop when a page is empty

[sujeito-operator]

fetchAllRepos in integrations/githubint/github_client.go pages the installation's repositories like this:

result, _, err := client.Apps.ListRepos(ctx, &github.ListOptions{Page: 1, PerPage: 100})
repos := result.Repositories
for len(repos) < *result.TotalCount {
    result, _, err = client.Apps.ListRepos(ctx, &github.ListOptions{Page: len(repos) / 100, PerPage: 100})
    ...
}

GitHub's pagination is 1-indexed, so len(repos) / 100 is the page we just read, not the next one.

What that does

For an installation with 250 repositories (three pages of 100/100/50):

iteration	len(repos)	page requested	should be
initial	0	1	1
1	100	1	2
2	200	2	3
—	300 ≥ 250, loop ends

Page 1 is fetched twice and page 3 is never fetched. The caller gets 300 entries for 250 repositories: 100 duplicates, and acme/repo-201..250 missing entirely. In the UI that reads as duplicated rows in the repository picker plus repositories that cannot be connected at all — which is easy to mistake for the repository not being visible to the installation.

And it can fail to terminate

The only exit is reaching TotalCount. If an installation reports more repositories than it will actually hand out, a page comes back empty while len(repos) is still short of TotalCount, the condition stays true, and the loop keeps calling the GitHub API — inside the HTTP request that triggered the listing. *result.TotalCount is also dereferenced without a nil check.

The change

Walk pages with an explicit 1-indexed counter, stop as soon as a page yields no repositories, and treat a missing total_count as "that was the last page". Same signature, same return value, no behaviour change for installations that fit on one page.

Verification

integrations/githubint/github_client_test.go drives fetchAllRepos against an httptest server that records which page numbers were requested, so no GitHub credentials or network access are needed. Three cases: single page, 250 repositories across three pages, and a server whose total_count overstates what it returns.

Against unmodified main the new tests fail exactly as described — the multi-page case reports acme/repo-201..250 missing, and the inconsistent-total_count case hits the test's 10s guard without terminating. With this change all three pass in 0.01s.

I ran the full suite on main and on this branch and the results are identical: 31 packages ok, and the same 9 pre-existing failures in database/repositories (TestAutoTenantScope*) and tests (TestGitleaksVulnPathThroughRealBackend), which need a Docker/testcontainers runtime this machine does not have. gofmt and go vet are clean. golangci-lint reports the same 7 pre-existing staticcheck findings before and after, all in github_integration.go, which this PR does not touch; 0 findings in either file it does touch.

Scope

This is only the paging bug. #2572 concerns the same repository-listing path but asks for orphaned-installation feedback and deletion on top of graceful degradation — I have deliberately not touched that here, since the hotfix in d688ab5 already keeps a dead installation from breaking the healthy ones, and the remaining parts of that issue are a UI/API surface question rather than this loop. Happy to pick that up separately if it would help.

One judgement call worth flagging: I kept PerPage: 100 as a named constant rather than making it configurable, since nothing else in the file parameterises it. Say the word if you would rather it stayed a literal.