ci(e2e): move heavy Docker lanes to larger GitHub-hosted runners

[apurvvkumaria]

Parent epic: #7140

Problem

The heaviest Docker/OpenShell E2E lanes run on the standard GitHub-hosted runner class. Their concurrent image builds, dependency installation, sandbox rebuilds, and cleanup can exhaust CPU, memory, or disk headroom and make hosted-runner loss difficult to distinguish from a product failure.

Adding more standard runners would reduce queue time, but it would not give an individual heavy job more resources. These lanes need a controlled larger-runner experiment.

Scope

• Create a dedicated GitHub-hosted larger-runner group, initially sized at 8 vCPU and 32 GB RAM with substantially more workspace disk than the standard class.
• Restrict the group to trusted NemoClaw workflows and branches according to repository security policy.
• Route only resource-heavy lanes initially:
  • common-egress-agent;
  • rebuild-hermes;
  • rebuild-hermes-stale-base; and
  • the heavy MCP bridge matrix entries identified by baseline telemetry.
• Set group maximum concurrency to 4–6 so the workflow does not move pressure from the VM to registries or shared services.
• Keep the runner label and eligible lane list centralized so rollout and rollback do not require broad workflow edits.
• Record queue time, execution time, peak CPU/memory/disk use, infrastructure failures, and estimated cost before and after migration.

Acceptance criteria

• The selected lanes run on the dedicated larger-runner group and unrelated fast lanes remain on standard runners.
• Maximum concurrency is explicitly configured and documented.
• At least five representative executions per migrated lane are compared with the standard-runner baseline.
• The comparison demonstrates useful resource headroom and reports duration, reliability, queue-time, and cost impact.
• Pull requests from untrusted forks cannot execute arbitrary code on a privileged or persistent runner.
• A documented rollback returns the selected lanes to standard runners without changing test semantics.

Follow-up threshold

If larger hosted runners still disappear without process-level failure evidence, evaluate trusted-main-only ephemeral self-hosted scale sets as a separate decision. Do not introduce persistent self-hosted runners in this issue.

[dfernandez365-rgb]

Fresh same-SHA evidence for two lanes already named in this issue:

• Commit: 70d7d287f03f82355eafccfc8084de3741069281
• Completed manual E2E run: 29766997258
• rebuild-hermes
• rebuild-hermes-stale-base

Each lane ran on a separate 15.6 GiB standard host. Both reached phase-one Hermes installation, drove one process above 12 GiB RSS, and then received GitHub's runner shutdown/cancellation sequence without a Vitest assertion or diagnostic artifact.

Last telemetry before loss:

Lane	Top process RSS	Available RAM	Free swap	Memory full-pressure avg10	I/O full-pressure avg10
rebuild-hermes	12.39 GiB	1.90 GiB	0.08 GiB	12.59	47.53
rebuild-hermes-stale-base	13.29 GiB	0.93 GiB	0.91 GiB	11.64	20.97

The runner then reported The runner has received a shutdown signal and The operation was canceled. Other failures in this run had ordinary assertions and uploaded artifacts, so they should not be counted as evidence for the larger-runner change. These two should.