fix(multi-pod): pin STUDIO_SANDBOX_RUNNER=docker to unblock attach-cross-pod

[tlgimenes]

What is this contribution about?

Fixes the attach-cross-pod multi-pod CI failure where POST /api/:org/decopilot/threads/:id/messages returned 409 link_unavailable / link_offline (see failing job).

Root cause: tests/multi-pod/docker-compose.yml didn't set STUDIO_SANDBOX_RUNNER, so resolveSandboxProviderKindFromEnv() defaulted to "remote-user". With no link daemon registered in CI, resolveDispatchTarget rejected the request before it could enqueue. PR #3434 removed the eager ensureVm() (which had been 500-ing) but the dispatch check that gates on link presence stayed, so the symptom shifted from 500 → 409 without fully fixing the test.

Pinning STUDIO_SANDBOX_RUNNER=docker on the mesh services makes resolveDispatchTarget short-circuit to the local cluster default (no link check), and no real sandbox is provisioned because ensureVm is lazy (built-in-tools/index.ts:159-184) and the mock-AI scenario never emits tool calls.

How to Test

1. Start Docker Desktop.
2. Run ./tests/multi-pod/run.sh.
3. attach-cross-pod should pass (along with the rest of the suite).

---

Summary by cubic

Pins STUDIO_SANDBOX_RUNNER=docker in tests/multi-pod/docker-compose.yml to fix attach-cross-pod failing with 409 link_offline on POST /api/:org/decopilot/threads/:id/messages. This forces local dispatch and avoids any sandbox provisioning since ensureVm is lazy.

• Bug Fixes
  • Unset runner defaulted to "remote-user", triggering a link check and 409 in CI. Setting it to docker short-circuits to the local cluster and unblocks the test.

^{Written for commit baf57c5. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}