#35716 cloud journey: exec through the machine route when the cmux CLI has none for a VM API machine

After #35475 gave the staging journey a cmux binary, every exec went through cmux machine access exec. On a VM API machine that command mints a client session, and the API refuses it: 501 Not Implemented cloud.provider.unsupported. So journey-staging went red at first exec (backend.yml run 41869364670, job 126724365942) and never got to login, chat, connect or sync.

What changes

cliExecWithFallback in scripts/cmux-next/cloud-journey.ts:

• The CLI's exec still runs first.
• When it answers cloud.provider.unsupported, the journey switches to the machine exec route (POST /v1/cloud/machines/{id}/exec, the guest route directExec already takes) for the rest of the run.
• The CLI gap goes into the journey's meta as exec_route.

Every other CLI failure stays the step's own.

The CLI gap itself, machine access exec having no VM API route, is left for a follow-up issue.

Tests

Two cases in cloud-journey.test.ts: the fallback, and another CLI failure that is kept as is.

🤖 Generated with Claude Code

Agent session: agent session

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the staging cloud journey failing at first exec on a VM API machine, where cmux machine access exec is rejected with 501 cloud.provider.unsupported because the machine has no client session.

• Runs the CLI exec first, then switches every subsequent exec to the machine exec route (directExec) once the CLI answers with that error.
• Records the CLI gap in the journey's meta as exec_route; other CLI failures still fail the step as before.
• Adds tests for the fallback and for keeping unrelated CLI failures as-is.