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
Refactors the guided setup path and changes flag creation from flags.Client to a direct API POST via resources.Client; wizard behavior is intended unchanged but touches authenticated API and local file install/inject flows.

Overview
Introduces internal/setup.Service with an Auth value so setup steps (list projects/environments, env keys, detect, install, create flag, inject, verify) live outside the TUI and never read viper. NewSetupCmd builds one service shared by the wizard and the hidden detect, install, and init subcommands, removing duplicated orchestration.

The Bubble Tea wizard is refactored from a single wizard.go into model.go, update.go, view.go, and commands.go; async work is thin tea.Cmd wrappers over setup.Service. flags.Client is dropped from NewSetupCmd / cmd/root.go; flag creation goes through resources.Client on the service (conflict still treated as success). Install-failure “don’t dead-end” behavior stays in the wizard; the install subcommand still returns errors.

Adds internal/setup/service_test.go for the new service methods.

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

[ari-launchdarkly]

Why not use the existing projects / environment commands?