test(control-plane): simplify and complete GitHub server coverage

[edersonbrilhante]

Overview

The EC2/compute-provider refactors in #5234 and #5246 established a provider-neutral boundary for control-plane orchestration. The next step is to make the remaining orchestration tests reflect that separation and treat GitHub server type as an independent, explicit test dimension.

The following suites are now about 3,700 lines combined, with scale-up.test.ts alone exceeding 2,300 lines:

• lambdas/functions/control-plane/src/pool/pool.test.ts
• lambdas/functions/control-plane/src/scale-runners/scale-down.test.ts
• lambdas/functions/control-plane/src/scale-runners/scale-up.test.ts

The module supports three GitHub server types:

• GitHub.com
• GitHub Enterprise Cloud with data residency (*.ghe.com)
• GitHub Enterprise Server (GHES)

Today, similar scenarios are implemented differently across the suites:

• scale-up.test.ts has three large, mostly copied server-specific blocks. Many test titles, setup sections, and batch fixtures are repeated, while other cases exist for only one server type without making it clear whether the omission is intentional.
• pool.test.ts gives GitHub.com the main behavior suite but gives GHES and data residency only one copied smoke case each.
• scale-down.test.ts is already table-driven, but uses raw endpoint strings and infers the server type through hostname matching rather than named, typed fixtures.
• Data-residency API expectations are inconsistent between suites and should be aligned with the production URL contract.

This makes coverage easy to drift and forces contributors to understand and update several large blocks to add one scenario. It is especially difficult for a new contributor to determine which duplication is required and which behavior is intentionally server-specific.

Goal

Introduce a small, typed GitHub server matrix and reusable scenario helpers. Common control-plane behavior should be declared once and run for every applicable server type; genuinely different behavior should remain explicit and easy to find.

The server fixture should model domain concepts directly, for example its display name, GHES_URL value, expected authentication/API URL, and expected runner base URL. It should not classify a server by testing substrings in a raw URL.

Keep this dimension separate from the compute-provider contracts: shared orchestration helpers must remain provider-neutral, while provider-specific behavior stays in the provider package.

Suggested scope

• Define one canonical typed fixture for GitHub.com, GitHub Enterprise Cloud with data residency, and GHES.
• Parameterize the common pool, scale-up, and scale-down server contracts with describe.each or small shared test functions.
• Keep server-independent scaling, batching, retry, eviction, and error scenarios declared once instead of copying them into each server block.
• Keep server-specific assertions explicit, including authentication/API URLs, organization versus repository registration, JIT configuration, and generated runner URLs.
• Consolidate repeated message, runner, environment, cache, and batch setup into focused factories with named overrides.
• Make environment isolation explicit, including removing GHES_URL for GitHub.com cases.
• Improve unclear test names and weak/repeated assertions while preserving production behavior.
• Keep EC2 terminology out of provider-neutral cases except where EC2 compatibility or default selection is specifically under test.

Acceptance criteria

• One typed server fixture defines GitHub.com, GitHub Enterprise Cloud with data residency, and GHES, including their environment, API/authentication, and runner base URL expectations.
• pool.test.ts, scale-down.test.ts, and scale-up.test.ts each run their applicable common server contract for all three supported server types.
• Common behavior is declared once; copied GitHub.com/GHES/data-residency suites and repeated batch/message/runner setup are removed.
• Tests verify that the expected server API URL reaches authentication/client creation and that generated runner configuration uses the expected base URL.
• GitHub.com cases explicitly clear enterprise configuration and no test depends on the caller's shell environment or another case's cache/mock state.
• Server-specific differences remain as focused tests rather than being hidden behind conditionals in a generic helper.
• Adding a supported GitHub server variant primarily requires adding one fixture entry, without copying an entire suite.
• Shared helpers remain compute-provider-neutral; EC2-specific implementation tests remain provider-owned.
• Existing behavior and meaningful coverage are preserved or improved, and the control-plane test, lint, formatting, and coverage checks pass.
• No production behavior changes are included. Any production defect exposed by the stronger contracts is tracked separately.

Related work

• Supersedes Refactor unit test for scale-up.test.ts #4393, which covered only scale-up.test.ts and was closed as stale without implementation.
• Follows the provider framework in refactor(runners): introduce provider plugin framework #5234 and the completed orchestration/EC2 test separation in test(control-plane): separate orchestration tests from EC2 provider tests #5246 (tracked by test(control-plane): separate orchestration tests from EC2 provider tests #5236).