Prefetch organization pending members

[john7doe]

What this does

Moves the organization pending member lookup into prefetch, which entitlements runs through a thread pool, instead of leaving it in calculate, which runs serially.

On a no-op deploy across a large set of organizations, that one call accounts for roughly half of the entire run.

Phase	Time	Runs concurrently
calculate	526s	no
of which pending member lookups	341s	no
prefetch and validate	148s	yes, sized by max_parallelism

The lookups are not redundant, so caching does not help. Each one is a different organization returning a different result, and every second of that 341s is time spent waiting on the API. The only way to shorten it is to let the requests overlap, and prefetch is already the phase built to do that.

How

GitHubOrg::Controller#prefetch now calls provider.pending_members alongside existing_groups. The result is memoized in Entitlements.cache[:github_pending_members], so changes reuses it later in calculate rather than issuing the request itself. The number of API requests is unchanged. Only the phase they happen in moves.

Three controller specs gained a pending_members stub on their provider instance_double, since those examples call prefetch directly. One strict call count went from two to three, because that example stubs the service rather than the provider and so bypasses the memoization that keeps the real request count flat.

GitHubTeam::Controller is left alone. Its prefetch already warms the provider reads that its calculate consumes.

Notes

This pays off only when max_parallelism is greater than 1. At the default of 1 the prefetch pool is serial as well, so the work still moves out of calculate but the wall time stays the same. Nothing regresses in that case, which makes this safe to land ahead of any consumer raising the value.

Full suite passes with 100 percent coverage and RuboCop is clean.