lakebox: explicitly start stopped sandbox before ssh

[akshaysingla-db]

Summary

Replaces the bare warn(ctx, "Starting <id>…") notice in lakebox ssh with an explicit api.start + waitForRunning sequence before exec-ing ssh.

The SSH gateway already auto-starts a stopped sandbox on connect, but that path is opaque — ssh hangs for minutes with no progress — and races the cold-start timeout. Driving the start from the CLI gives the user a visible spinner with elapsed time and a deterministic timeout (the same one databricks lakebox start uses). The new ensureRunning helper also handles already-transitioning states (Creating, Starting) — it skips the api.start RPC and just polls. The fresh sandboxEntry returned by the helper also refreshes the cached GatewayHost if it changed during the start.

User-visible change

Before:

! Starting happy-panda-1234… (may take a few minutes)
⠋ Connecting to happy-panda-1234…   ← hangs silently, can time out at the ssh layer

After:

⠋ Starting happy-panda-1234… (8s)
⠋ Starting happy-panda-1234… (10s)
…
✓ Started happy-panda-1234
⠋ Connecting to happy-panda-1234…   ← fast, sandbox already running

Test plan

• go test ./cmd/lakebox/... passes
• go build ./... clean
• Live test against a stopped sandbox (deferred — 5–10 min wall clock per attempt)

This pull request and its description were written by Isaac.

[github-actions]

Waiting for approval

Based on git history, these people are best suited to review:

• @pietern -- recent work in cmd/lakebox/

Eligible reviewers: @andrewnester, @anton-107, @denik, @renaudhartert-db, @shreyas-goenka, @simonfaltum

_{Suggestions based on git history. See OWNERS for ownership rules.}