Restore Mirror Cluster Picker Feature

Bottom line: it's not gone — you deliberately scoped it down yourself, in the same PR that added it. The cluster picker was confined to the bare no-args wizard; create owner/repo was reverted to the fixed default cluster before the PR ever merged.

• The whole arc happened inside https://github.com/entireio/cli/pull/1519 (cor-645-cli-smooth-mirror-onboarding-flow, merged June 26):

  • 993f948bf (Jun 24) added the onboarding wizard with the region multi-select fed by GET /api/v1/clusters.
  • 289a796c8 + 6f7d46408 (Jun 25) made the one-shot create <github-url> resolve its cluster from the same catalog (jurisdiction-aware default, printed "Using default cluster X" — it auto-picked, it never showed a list on this path).
  • 68e81f383 (Jun 25, during PR review) reverted exactly that: "Limit cluster guessing to the interactive wizard… so non-interactive invocations (and scripts) keep stable, predictable defaults." It deleted resolveDefaultClusterHost/callerJurisdiction/pickDefaultRegionHost and put the one-shot back on the hardcoded defaultClusterHost = "aws-us-east-2.entire.io" (cmd/entire/cli/repo_mirror.go:55).

• So current behavior on main is intentional and consistent:

  • entire repo mirror create (bare) → interactive wizard, repo picker + cluster/region multi-select, jurisdiction-ordered. Still alive and well in repo_mirror_create_wizard.go.
  • entire repo mirror create owner/repo → one-shot, fixed us-east-2 default unless you pass [cluster-host] as the second arg. No catalog call, no picker.

• The rationale recorded in the revert commit: scripts and non-interactive callers should get a stable default rather than a network-dependent, jurisdiction-dependent guess.

If you now want the arg-form to prompt with a cluster list when running on a TTY (falling back to the fixed default non-interactively — same pattern as entire repo clone's "prompt only when several clusters are possible"), that's a small change since availableRegions/clusterChoices already exist. Say the word and I'll wire it up.

API Error: Connection closed mid-response. The response above may be incomplete.

The background test:ci run will notify me when it completes — no extra monitor needed. Status so far: change implemented and reviewed, unit tests + lint + fmt all green; waiting on the full CI suite (integration + canary) before committing and opening the PR.

PR is up: https://github.com/entireio/cli/pull/1645

• entire repo mirror create owner/repo on a TTY now fetches the cluster catalog and prompts with a single-select when [cluster-host] is omitted — jurisdiction default pre-selected, prompt skipped when only one cluster exists (same shape as repo clone). Non-interactive runs keep the fixed aws-us-east-2.entire.io default with no network lookup, so the script-stability concern that motivated the #1519 revert is preserved.
• Implementation reuses the wizard's existing availableRegions/clusterChoices; new code is resolveOneShotClusterHost + pickOneCluster in repo_mirror_create_wizard.go, plus a test locking in the non-interactive fallback.
• Verified: mise run fmt, mise run lint (0 issues), and full mise run test:ci (unit + integration + canary) all green.
• One wrinkle: git push origin was rejected by the entire:// mirror ("link your GitHub account at entire.io"), so I pushed the branch directly to git@github.com:entireio/cli.git without touching your remote config. You may want to link GitHub on entire.io so mirror pushes work again.

Bottom line: yes, it's defensive-only — the failure it describes isn't reachable, and even if it were, the code fails closed. But the 3-line guard would match the repo clone precedent, so it's a cheap "make Copilot happy" if you want it.

• Not reachable: pickOneCluster only runs when len(regions) >= 2, so the Select always has options. When a huh Select form completes without error, it writes the highlighted option's value into selected — there's no successful-submit path that leaves it empty or off-list. Cancel/Ctrl+C goes through the error branch we already handle.
• Fails closed anyway: the hypothetical empty value would hit validateClusterHost("") in the caller and error out with "invalid [cluster-host]: cluster host is empty" — slightly misattributed wording, but no wrong cluster gets used, and no security angle (every offered host already passed hostFromPublicURL's validation).
• The only substance in the comment is consistency: selectCloneTarget in repo_clone.go:268 does guard its selection with a map lookup, so this picker is marginally less paranoid than its sibling.

My call: resolve it as not-a-bug, or say the word and I'll add the map-lookup guard for symmetry — either is defensible, and I wouldn't spend review-cycle time on it beyond that.

Guard added, lint clean; full test:ci running in the background. I'll commit and push once it passes.