infra-setup

# Infra Setup Use this when the user wants to change where experiments run: local worktrees, pool slots, or a remote provider such as Modal, E2B, Daytona, AWS, Azure, SSH, manual, or a custom dotted-path provider. ## Goals - Be explicit about the target backend/provider. - Check prerequisites before mutating evo config. - Never install provider SDKs silently. - Give one actionable auth command per provider. - Keep provider credentials separate from benchmark runtime env. ## Flow 1. Identify the target: - `worktree` or `pool` means local backends. - `modal`, `e2b`, `ssh:...`, or another remote spec means `backend=remote`. 2. If the target is remote, parse the provider choice the same way evo CLI does: - `modal` - `e2b` - `daytona` - `aws` - `azure` - `manual` - `ssh:user@host[:port]` - another built-in provider name - dotted import path for a custom provider 3. Check whether `evo` is on PATH and whether it is the expected `evo-hq-cli` package (`evo --version`). If the provider SDK is missing, evo's provider loader prints the provider-specific extra or SDK package to install; use that message rather than guessing. 4. For SDK-backed providers, verify the SDK import only when you can run the check in the same environment that owns the `evo` executable. If missing, ask the user before installing it. - If `evo` was installed with `uv tool` or `pip`/`venv`, prefer the matching extra on `evo-hq-cli`: - `uv-tool`: `uv tool install --reinstall 'evo-hq-cli[<prov...