[Community] Provision GPU capacity for Community CI

Summary

Provision secure GPU capacity that can run qualification workloads for community pull requests without depending on manually available internal machines.

The solution must preserve a strict trust boundary: untrusted pull-request code must not gain access to repository secrets, persistent runner credentials, private infrastructure, or artifacts from other jobs.

Tasks

• Define the initial GPU, operating-system, architecture, TensorRT, CUDA, and driver matrix.
• Select the hosting model and establish an operating budget.
• Configure isolated runners with least-privilege access and reproducible environments.
• Define authorization rules for running community-submitted code on GPU infrastructure.
• Ensure jobs cannot access long-lived credentials, unrelated workloads, or residual data from previous jobs.
• Connect the runners to the Community CI workflow.
• Add at least one representative GPU qualification job.
• Pin each run to the exact pull-request revision being evaluated.
• Add public queue visibility, queue-time reporting, timeout handling, cancellation, and actionable failure reporting.
• Publish sanitized qualification results without exposing private infrastructure details.
• Monitor utilization, cost, queue time, reliability, and available capacity.
• Document capacity limits and the process for expanding the initial matrix.
• Document ownership for runner maintenance, security updates, credential rotation, and incident response.

Acceptance criteria

An authorized community pull request can trigger at least one representative GPU qualification job and receive public, actionable results for its exact revision without manual machine provisioning.

The qualification environment is isolated, least-privilege, reproducible, observable, and covered by documented maintenance and incident-response ownership.

Start by reviewing the Community CI workflow and the acceptance criteria, then define the initial GPU qualification matrix, hosting model, isolation rules, and authorization boundaries. Done means an authorized community pull request runs a representative GPU qualification job for its exact revision and receives public actionable results, with documented ownership, observability, and incident response.