feat(install): show the whole team in the environment picker

[nicknisi]

Stack: #229 → #230 → #231 → this. Retarget as bases merge.

Why

The install picker listed only the profiles this machine already knows about, while the dashboard shows the team's full environment list. Choosing from a visibly different list than the dashboard is exactly the disorientation this stack set out to fix.

What

The picker now merges in the team's environments (fetched best-effort with the existing session via fetchTeamEnvironments; offline or logged-out degrades to the local-only picker):

  Your team has 21 environments; 5 are ready on this machine — pick the one this app should call home.
  ○ rows need an API key here first: workos profile add <name> <api-key> --client-id <client-id>

? Which WorkOS environment should this install use?
❯ cli-branding-smoke > Staging        staging-3 · Sandbox ● active
  Nick's Team's Project > test12      staging · Sandbox
  Nick's Team's Project > Production  ○ no API key on this machine

• Environments already represented by a keyed profile (clientId or environmentId join) are not duplicated
• Unkeyed environments are disabled rows, not selectable: the dashboard catalog has no operation that creates or reveals an sk_ secret (verified exhaustively — only apiKeys metadata, deleteApiKey, expireApiKey), so the CLI cannot make them installable on its own. Showing them with the enable recipe is the honest middle
• Now prompts when one keyed profile coexists with other visible team environments (previously silent); zero keyed profiles or a truly forced pick stays silent
• ui.select gains a disabled option flag (plumbed to inquirer)

Verification

2720 tests passing (3 new: disabled-row shape + note recipe, single-profile-plus-team prompting, discovery-failure degradation), typecheck + oxfmt clean.

[greptile-apps]

Greptile Summary

The PR expands the install environment picker with the authenticated team's environment catalog and disabled rows for environments lacking local API keys. It also moves selection into installer startup, adds bounded discovery, and extends the dashboard request and UI abstractions with cancellation and disabled-option support.

• Merges keyed local profiles with team environments without duplicating joined entries.
• Falls back to local profiles when the session is unavailable, expired, offline, or slow.
• Adds installer cancellation handling and picker-focused tests.

Confidence Score: 4/5

The PR is not yet safe to merge because an already-aborted discovery signal can still start a dashboard request that keeps the CLI alive until its transport timeout.

The new cancellation bridge listens only for future abort events, while team discovery performs asynchronous imports before request initialization; if the three-second deadline expires during those imports, the later dashboard request misses cancellation and can retain its socket and timeout.

Files Needing Attention: src/lib/dashboard-graphql.ts and src/lib/resolve-install-credentials.ts

Important Files Changed

Filename	Overview
src/lib/resolve-install-credentials.ts	Adds team discovery, catalog joining, disabled picker rows, and a bounded fallback, but its pre-request asynchronous work exposes the already-aborted-signal edge case.
src/lib/dashboard-graphql.ts	Adds caller cancellation forwarding, but only future abort events are forwarded to the internal request controller.
src/lib/environment-target.ts	Propagates the optional AbortSignal through team-environment discovery.
src/lib/run-with-core.ts	Runs interactive environment selection after adapter startup and before the installer machine begins.
src/utils/ui.ts	Passes disabled choice metadata through the shared select facade.
src/commands/install.ts	Preserves structured CliExit outcomes instead of reclassifying picker cancellation as an installer error.
src/lib/resolve-install-credentials.spec.ts	Covers discovery failure, ordinary timeout cancellation, expired sessions, disabled rows, and prompt behavior, but not request initialization after the signal is already aborted.

Sequence Diagram

sequenceDiagram
  participant I as Installer
  participant P as Environment picker
  participant T as Discovery timer
  participant G as Dashboard GraphQL
  I->>P: Start environment selection
  P->>P: Load credentials and environment modules
  P->>T: Start 3-second deadline
  alt Discovery starts before deadline
    P->>G: Fetch team environments with signal
    T-->>G: Abort underlying request on timeout
  else Deadline fires before request initialization
    T-->>P: Abort caller signal
    P->>G: Initialize request with already-aborted signal
    Note over G: Request must immediately inherit aborted state
  end

Loading

Prompt To Fix All With AI

### Issue 1
src/lib/dashboard-graphql.ts:105
**Already-aborted signal is ignored**

When the discovery deadline expires while the preceding dynamic imports are still pending, `sendDashboardRequest` receives an already-aborted signal but subscribes only to future abort events. The dashboard fetch therefore starts with a live controller and can retain its socket and timeout for thirty seconds, causing a cancelled or quickly completed install to linger.

```suggestion
  if (options.signal?.aborted) {
    controller.abort();
  } else {
    options.signal?.addEventListener('abort', () => controller.abort(), { once: true });
  }
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (10): Last reviewed commit: "fix(install): cancel team discovery's re..." | Re-trigger Greptile}

[nicknisi]

0d4f5aa repositions the picker per review: it now renders after the AuthKit brand mark and before the machine starts (branch prompt, detection), instead of pre-banner. Flow reads: banner → pick environment → install steps. Bonus: the machine's auth check now runs after the pick, so choosing a profile that needs a login triggers the in-flow device auth instead of relying on pre-flight state. handleInstall also learned to rethrow CliExit so the picker's cancel stays a clean exit 2.

[greptile-apps]

Already-aborted signal is ignored

When the discovery deadline expires while the preceding dynamic imports are still pending, sendDashboardRequest receives an already-aborted signal but subscribes only to future abort events. The dashboard fetch therefore starts with a live controller and can retain its socket and timeout for thirty seconds, causing a cancelled or quickly completed install to linger.

Suggested change

	options.signal?.addEventListener('abort', () => controller.abort(), { once: true });
	if (options.signal?.aborted) {
	controller.abort();
	} else {
	options.signal?.addEventListener('abort', () => controller.abort(), { once: true });
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/dashboard-graphql.ts
Line: 105

Comment:
**Already-aborted signal is ignored**

When the discovery deadline expires while the preceding dynamic imports are still pending, `sendDashboardRequest` receives an already-aborted signal but subscribes only to future abort events. The dashboard fetch therefore starts with a live controller and can retain its socket and timeout for thirty seconds, causing a cancelled or quickly completed install to linger.

```suggestion
  if (options.signal?.aborted) {
    controller.abort();
  } else {
    options.signal?.addEventListener('abort', () => controller.abort(), { once: true });
  }
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.