ci(e2e): establish trusted Jetson execution through Colossus-backed dispatch

[jyaunches]

Problem Statement

NemoClaw has Jetson-specific end-to-end coverage, but GitHub does not currently provide a supported Jetson runner. The explicit Jetson target can therefore validate workflow behavior without providing the hardware execution needed by changes such as #8099.

#6430 made runner unavailability bounded and actionable. It intentionally did not establish owned Jetson capacity.

Desired Outcome

Establish a trusted CI path that lets a GitHub Actions workflow dispatch NemoClaw E2E jobs to team-owned Jetson hardware through Colossus or an equivalent controlled execution service, then return the exact result, logs, and artifacts to the originating workflow.

Colossus support is a feasibility question, not an assumed dependency. The team has also requested AGX Thor T4000 and T5000 systems through MRS, which may provide the initial hardware pool if Colossus cannot supply Jetson capacity directly.

Design Questions

• Can Colossus provision or securely reach the required Jetson AGX Thor/Orin hardware?
• Should GitHub Actions dispatch to a Colossus job, a gateway in front of the MRS-provided systems, or a tightly controlled self-hosted runner?
• How are hardware reservation, health checking, clean-state restoration, concurrency, timeout, retry, and cleanup enforced?
• How are credentials and the runner host protected from fork pull requests and other untrusted changes?
• Which Jetson variants and JetPack versions form the required validation matrix?

Acceptance Criteria

• Record an owned design decision for Colossus-backed execution or the selected alternative.
• Restrict hardware execution to an allowlisted trusted workflow and document the trust boundary for pull-request code.
• Dispatch the existing Jetson E2E target to a real Jetson system from GitHub Actions.
• Return a bounded pass/fail result, logs, and artifacts to the originating workflow.
• Restore a known clean state after success, failure, cancellation, and timeout.
• Report unavailable capacity without indefinitely blocking workflow aggregation, preserving ci(e2e): prevent an unavailable Jetson runner from blocking workflow finalization #6430.
• Run the relevant Jetson E2E coverage for an exact fix(onboard): permit Jetson GPU policy paths #8099 commit and record the tested hardware and JetPack version.

Related Work

• [Jetson][Sandbox] Sandbox GPU passthrough proof fails for the non-root sandbox user on JetPack 6.2 IGX Orin — onboarding aborts #7610 — current Jetson GPU passthrough defect requiring hardware validation
• fix(onboard): permit Jetson GPU policy paths #8099 — current fix awaiting Jetson E2E evidence
• ci(e2e): prevent an unavailable Jetson runner from blocking workflow finalization #6430 — bounded handling when no Jetson runner claims the job
• test(e2e): migrate test-jetson-nvmap-gpu.sh to vitest #5613 — introduced the Jetson nvmap E2E target

Source Discussion

• Internal Slack thread: #nemoclaw-situation-room

Checklist

• I searched existing issues and this is not a duplicate
• I described the problem, decision boundary, and desired outcome

[sandl99]

Temporary implementation plan:

1. Run cloudflared on the Colossus host and expose one authenticated HTTPS dispatch endpoint.
2. Add a trusted GitHub Actions controller that sends the exact NemoClaw commit and fixed jetson-nvmap-gpu target to that endpoint.
3. Have the Colossus dispatcher validate the request, acquire an exclusive device lock, and connect to the Jetson over SSH.
4. Run the existing Jetson E2E test and return its result, logs, hardware identity, and JetPack version to GitHub Actions.
5. Apply a bounded timeout and reset the Jetson after success, failure, cancellation, or timeout.

I will own the implementation. Colossus retains the tunnel and SSH credentials, and candidate code runs only on the Jetson.