[Bug]: Pull requests page takes 1-3 minutes with ~180 GitLab projects #33299

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Add ~180 projects on one GitLab host to an environment.
2. Open the Pull requests page.

Expected behavior

The list loads in seconds, like it does for GitHub projects.

Actual behavior

pullRequests.list takes 73-176 s and filterOptions ~134 s. One load spawns ~850 glab processes (357 listMergeRequests, 172 listProjectUsers, ~170 listProjectLabels, 104 supportsGraphqlList). Until it returns, the page is empty and the refresh spinner keeps going, even if another environment has already answered.

From the server code:

• GitLab has no listChangeRequestsAcross, so listUncached reads every project separately. "Authored" and "reviewing" filter afterwards and don't reduce the work.
• filterOptions reads labels and authors of every project each time the page opens.
• graphqlListSupport is cached by [cwd, host], so the GraphQL probe runs per checkout instead of per host.

Suggested fix

Add listChangeRequestsAcross for GitLab: GraphQL projects(fullPaths: [...]) { nodes { mergeRequests(...) } } reads many projects in one request. Also cache the GraphQL probe per host and load label/author options when the picker opens.

Impact

Major degradation or frequent failure

Version or commit

0.1.8-nightly.20261109.4399

Environment

Linux server, glab 1.122.0, self-hosted GitLab; macOS desktop client.

Workaround

Filter by host or by one project.