codewhale remote-setup wizard: guided cloud + chat-bridge + provider setup (/remote)

[Hmbown]

Goal

Implement codewhale remote-setup — the interactive wizard designed in docs/REMOTE_SETUP_DESIGN.md — so that standing up a phone-controlled remote workbench (cloud VM + chat bridge + provider) becomes a guided in-product flow instead of a runbook: pick cloud, pick bridge, pick provider, get prompted for exactly the right secrets, receive a generated deploy bundle (env files, systemd units, RUNBOOK), optionally auto-provision behind a printed-plan confirmation gate.

User phrasing of the need: "a /remote thing that makes it easy to set up your Feishu/Lark / Telegram + DigitalOcean / Tencent Lighthouse and cues you for the right keys."

Design

Already written: docs/REMOTE_SETUP_DESIGN.md (table-driven CloudTarget × BridgeSpec × ProviderSpec, native Rust subcommand in crates/cli + crates/tui, generate-only by default, --apply gated, secrets never via argv). This issue is the implementation tracker; deltas from the design doc as written:

• Add DigitalOcean as a CloudTarget row (the design lists Lighthouse/Azure with "extensible"). The v0.8.56 smoke lane validated DO end-to-end; scripts/remote-smoke/digitalocean/provision.sh is the reference for provision/digitalocean.rs (region/size/price preflight via API, SSH key import, SSH-only firewall, typed-yes billing gate, teardown with leftover-billing check).
• First shipped pair: DigitalOcean × Telegram (matches the proven lane), with Lighthouse × Feishu next since its scripts/templates already exist.
• Templates must encode the sharp edges found in the v0.8.56 smoke (see v0.8.56: Ship DigitalOcean + Telegram remote-workbench setup #2964): runtime binary reads DEEPSEEK_RUNTIME_TOKEN/flags only — env names work via systemd ExecStart expansion; pre-create ~/.codewhale + ~/.deepseek (ReadWritePaths); install prebuilt release binaries to /home/codewhale/.cargo/bin/ instead of building Rust on the VM.
• Namespace migration (DEEPSEEK_* → CODEWHALE_* with fallback) lands with or before this, per the design doc's touch list.

Scope

1. crates/tui/src/remote_setup/ module per the design layout (registry, prompts, bundle renderer, provisioners).
2. CLI: Commands::RemoteSetup with --cloud/--bridge/--provider/--out/--generate-only/--apply/--yes/--non-interactive.
3. Clouds: digitalocean (new), lighthouse (existing templates); Azure may follow.
4. Bridges: telegram, feishu (both bridge implementations already exist under integrations/).
5. Providers: read the existing PROVIDERS registry; prompt for env_keys[0].
6. Tests per the design doc (registry uniqueness/path existence, bundle rendering for each triple, provision plans built-not-executed).

Non-goals

• Webhook/public-ingress modes; Discord/Slack bridges (new BridgeSpec rows later).
• Replacing the v0.8.56 script lane — those scripts remain the manual/CI path and the wizard's template source.

Acceptance criteria

• codewhale remote-setup --cloud digitalocean --bridge telegram --provider deepseek --generate-only emits a bundle whose RUNBOOK + env files + units reproduce the proven v0.8.56 lane (modulo secrets).
• --apply prints the full ordered provisioning plan and requires confirmation before any billable API call; secrets are fed via stdin/temp files, never argv.
• Wizard prompts adapt to the chosen bridge/provider (secret_keys, setup_hint, provider key var) — "cues you for the right keys."
• Adding a new cloud or bridge is one registry row + one module, no wizard control-flow changes.

Links

• Design: docs/REMOTE_SETUP_DESIGN.md
• Proven lane + sharp edges: v0.8.56: Ship DigitalOcean + Telegram remote-workbench setup #2964, scripts/remote-smoke/
• Evaluation context: Remote workbench: evaluate US-first Cloudflare/AWS/Telegram lane #1990
• Bridges: integrations/telegram-bridge/, integrations/feishu-bridge/