Optimize internal job request endpoint to return applicable runner controllers

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

When the Job Router (KAS) routes a job with admission control, it currently makes two separate HTTP calls to GitLab Rails:

1. Job request: KAS proxies the runner's job request to the public POST /api/v4/jobs/request endpoint (lib/api/ci/runner.rb:228), which calls Ci::RegisterJobService to assign a job.
2. Runner controllers for admission: KAS calls GET /api/v4/internal/ci/job_router/runner_controllers/job_admission (ee/lib/ee/api/internal/ci/job_router.rb:80) to fetch all applicable runner controllers.

We can optimize this by creating a new internal job request endpoint (e.g. POST /api/v4/internal/ci/job_router/jobs/request) that combines both behaviors into a single call — returning the job data along with the applicable runner_controllers in one response. Note: There is currently no internal job request endpoint; KAS proxies the public POST /api/v4/jobs/request directly. The dedicated GET .../job_admission endpoint should remain in place for backwards compatibility until KAS is fully migrated to the combined endpoint.

This will most likely be obsolete when we phase out the "proxy" job router and move to Push-based job dispatch in Job Router (gitlab-org#21091).