Large number of forks causes long page load times

### Describe the bug

When using the private mirrors UI to view the list of forks for an organization that contains a large number of forks the page can take a long time to initially load despite the use of pagination.

### To Reproduce

1. Open the private-mirrors UI
2. Open the browser developer console to ensure that network logs are being captured
3. Navigate to an organization that contains a lot of mirrors (in testing 150 repositories cause the load to take about 30 seconds)
4. Look through the network logs and add up the time that it takes for all of the ["getReposInOrgGQL" queries](https://github.com/github-community-projects/private-mirrors/blob/fdcb497ca912903d26f9d32b999d1054a618379a/src/bot/graphql.ts#L156) to run

### Expected behavior

The private-mirrors UI should effectively paginate and lazy load the fork list to avoid making the user wait for all fork details to load before displaying any of them. The ["getReposInOrgGQL" query](https://github.com/github-community-projects/private-mirrors/blob/fdcb497ca912903d26f9d32b999d1054a618379a/src/bot/graphql.ts#L156) and [useForksData function](https://github.com/github-community-projects/private-mirrors/blob/fdcb497ca912903d26f9d32b999d1054a618379a/src/hooks/useForks.tsx#L58) should also be investigated to determine if other optimizations can and should be made.

### Screenshots

_No response_

### Additional context

_No response_

Read src/bot/graphql.ts around getReposInOrgGQL and src/hooks/useForks.tsx around useForksData, then reproduce the delay with an organization containing many mirrors while recording network logs. Identify why the paginated UI waits on multiple fork-detail queries; done means the fork list displays without waiting for all details and the request time is reduced.

Written by the indexing model from the issue text.