refactor(setup): move orchestration out of the wizard UI

[ffantl-ld]

Describe the solution you've provided

Moves the setup orchestration out of the UI layer. Adds a Service in internal/setup (with an
Auth value for credentials, so it never reads viper) that owns every step — list projects/
environments, fetch env keys, detect, install, create flag, inject, verify. The Bubble Tea wizard
becomes a thin adapter over the service, and the detect/install/init subcommands call the same
service, removing the wizard-vs-subcommand duplication. The flow is now unit-testable without driving
the TUI.

wizard.go (871 lines) is split into model.go / update.go / view.go / commands.go. The
Update state machine (screen sequencing) is unchanged.

Related issues

Top of the setup-ld feature stack — cleanup on top of the setup command. Stacked PR: base is
ffantl/setup-ld/6-command.

Additional context

• Project/environment reads and flag creation go through resources.Client (drops the unused
  flags.Client arg from NewSetupCmd; one-line change in cmd/root.go).
• The "don't dead-end on install failure" behavior stays in the wizard (UI-flow policy); the
  non-interactive install subcommand still returns a real error.

Requirements

• I have added test coverage for new or changed functionality

---

Note

Medium Risk
Touches authenticated API flows, local file injection, and package install execution; behavior is largely preserved but centralized, with new unit tests reducing regression risk.

Overview
Moves setup orchestration into internal/setup.Service, with an Auth struct so the layer never reads viper. The service owns listing projects/environments, env SDK keys, detect/install, flag creation (including conflict-as-success), inject, and verify. NewSetupCmd now takes setup.Clients (projects, environments, flags, resources); cmd/root.go wires all four instead of passing resources/flags alone.

The Bubble Tea wizard is a thin adapter: commands.go maps tea.Cmd handlers to service methods; the monolithic wizard.go is split into model.go / update.go / view.go / commands.go without changing the step flow. Install-failure “continue with manual command” stays in the wizard; detect / install / init call the same service (non-interactive install still returns errors).

Adds EnvironmentsClient.List (and mock) for environment listing. service_test.go covers API parsing, flag conflict handling, and passthrough steps with mocks/fakes.

^{Reviewed by Cursor Bugbot for commit f9f0996. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ari-launchdarkly]

Why not use the existing projects / environment commands?

[ffantl-ld]

Good call — done in df96562.

ListProjects, ListEnvironments, EnvKeys, and CreateFlag now go through the existing projects/environments/flags clients.

Two notes:

• The environments client only had Get, so I added List to it.
• Verify still uses resources.Client. It polls .../environments/{env}/sdk-active, which has no method in the generated ldapi SDK — we'll handle cleaning this one once we add the endpoint to the ldapi sdk if that's worth doing.

Verified by walking the full wizard against a real project in a clean container.

[ffantl-ld]

I'm not married to the idea of a struct here for these interfaces, btw. There are pros and cons between passing the interfaces as params, or just bundling them in a struct.