cloud: first-party executor via Hermes (reduce single-provider Rush dependency)

[muqsitnawaz]

Part of #321 · Tier 2 · Surface: cloud (strategic dependency risk)

Summary

We are a thin client over three third-party cloud providers (Rush api.prix.dev, Codex, Factory). If Rush goes down or changes terms, our primary execution path goes with it, and we control neither latency, sandboxing, nor billing. Make the Hermes gateway a first-party execution backend so agents cloud run --provider hermes dispatches to infrastructure the user controls.

Current behavior (this repo)

• src/lib/cloud/registry.ts registers rush, codex, factory providers; we own none of the compute.
• Codex provider stream() polls every 5s (src/lib/cloud/codex.ts) — no real-time output.

The gap (competitors — June 2026)

• Warp Oz — owns hosted infra + self-hosted K8s option.
• Cursor Cloud, Devin, Factory — each owns its compute/sandboxes.

Why it matters

Being a client-only dispatch layer is a defensible starting point, but every category leader owns their compute. A first-party backend (self-hostable via Hermes) removes the single point of failure and lets us guarantee sandboxing/latency/billing — and pairs naturally with the event triggers (#331) and web dashboard (#330).

Proposed implementation

• Implement a hermes cloud provider conforming to the existing CloudProvider interface (dispatch/status/list/stream/cancel/message).
• Hermes pod clones the repo, runs the agent, streams SSE, returns prUrl — the same contract as Rush, but self-hostable.

Acceptance criteria

• agents cloud run --provider hermes dispatches to a self-hosted Hermes pod and streams output live.
• Feature parity with the Rush provider for the core dispatch lifecycle.
• Falls back/coexists with existing providers; no regression to Rush/Codex/Factory paths.

Effort: XL (infra) · Priority: P2