deploy-flyte-kind-vm: document console + tunnel-free SDK access from a cloud VM (DigitalOcean), run-URL host mismatch, and -N/doctl pitfalls

## Summary

Follow-up to #18, this time for the **`deploy-flyte-kind-vm`** skill (the cloud-VM variant). I deployed Flyte-on-kind to a **DigitalOcean droplet** and it worked end-to-end (test runs completed all task pods against Supabase + R2), but a few VM-specific things were rough or undocumented — mostly around **browser/SDK access from the user's machine to the VM**. The storage config gaps from #18 also apply here since this skill hands off to `deploy-flyte-kind`.

Setup: droplet `s-4vcpu-8gb` / nyc1, Ubuntu 24.04, kind + flyte-binary v2.0.27, Supabase (session pooler) + Cloudflare R2, flyte SDK 2.5.8.

---

## VM-specific issues / gaps

### 1. Browser console on a VM isn't covered by the base (no-auth) path
The base deploy installs no ingress controller, so the console is unreachable the same way as #18 — but on a VM you can't just `kubectl port-forward` the console and browse `localhost`. What works cleanly:

- Install **Traefik** (the skill only does this in the optional *auth* section) with `service.type=NodePort`, `ports.web.nodePort=30080`, `ports.websecure.nodePort=30443` — matching the kind host-port mappings the skill already creates (`30080→80`, `30443→443`).
- Add two `IngressRoute`s for a **unified origin** (the console frontend calls the API same-origin — see #18): `PathPrefix('/flyteidl2.')` → `flyte-http:8090` (scheme `h2c`), and `/` → `flyte-console:80`.
- Because kind maps the droplet's **host port 80** → Traefik, the console is then reachable **directly at `http:///v2`** (firewall already scoped to your IP) — no tunnel at all. Or tunnel it: `ssh -N -L 8080:localhost:80 root@`.

Suggest adding a short "Access the console from a VM (no auth)" recipe covering the Traefik install + the two routes + direct public-IP access.

### 2. SDK can be tunnel-free too — the skill only shows the SSH tunnel
Step 4 documents the SDK access as an SSH tunnel + `kubectl port-forward` only. Once Traefik is routing `/flyteidl2.*` (item 1), the SDK can point **straight at the VM's public IP** and drop the tunnel entirely:

```yaml
# .flyte/config.yaml
admin:
endpoint: dns:///:80
insecure: true
```

gRPC rides Traefik's `web` entrypoint over **h2c** on port 80 and works (verified a full run with every SSH tunnel stopped). Worth mentioning as the lower-friction option for evaluation, with the caveat that it's plain HTTP over the public internet (firewall-scoped to your IP).

### 3. Run URLs are advertised as `localhost:8080` regardless of host
`flyte run` prints `URL: http://localhost:8080/v2/...` even when deploying to a VM. On a VM those links are dead — the user has to manually swap the host to ``. Would be good to (a) note this in the skill, and/or (b) file upstream to make the console base URL configurable so VM deploys advertise the right host.

### 4. `-N` pitfall on the SDK tunnel
The Step 4 tunnel that runs a remote command —
`ssh -L 8090:localhost:8090 root@ kubectl -n flyte port-forward ...` — must **not** include `-N`: `-N` tells SSH not to execute the remote command, so `kubectl port-forward` never starts and the forward gets `connection refused`. The skill's example is correct (no `-N`), but a one-line warning would save people who add it out of habit. (Conversely, the pure console tunnel in item 1 *does* want `-N` since there's no remote command.)

### 5. `doctl` prerequisite / non-interactive auth
Minor: the skill assumes `doctl` is installed and authenticated. Worth noting `brew install doctl` and that auth can be done non-interactively with `doctl auth init -t ` (handy when a token is pasted rather than entered at the prompt). Also that the SSH key must be **imported to DO** first (`doctl compute ssh-key import --public-key-file ~/.ssh/id_ed25519.pub`) and its ID passed to `droplet create`.

---

## Suggested skill improvements
1. Add a **"Console + SDK access from a VM"** section: Traefik install + the two unified-origin IngressRoutes, then both (a) direct public-IP access `http:///v2` and (b) tunnel-free SDK `endpoint: dns:///:80`.
2. Note the **`localhost:8080` run-URL host mismatch** on VMs (and consider an upstream ask to make the console base URL configurable).
3. One-line **`-N` warning** on the SDK tunnel command.
4. Brief **`doctl` setup notes** (install, `-t` token auth, ssh-key import).
5. Cross-reference #18 so VM users apply the task-pod `FLYTE_AWS_*` env vars and `runs.storagePrefix` override (required for tasks to run).

Happy to send a PR bundling #18 + this into the two skill docs.

_Teardown was clean: `doctl compute droplet delete flyte-kind` + firewall + ssh-key; Supabase/R2 untouched._

Start by reading the deploy-flyte-kind-vm skill, especially Step 4 and its optional auth section, then compare the related guidance in #18. Update the skill with the VM console and SDK access recipes, run-URL caveat, -N warning, doctl setup, and #18 cross-reference; done means each documented access path and prerequisite is covered.

Written by the indexing model from the issue text.