feat(orbit): add `glab orbit setup` guided onboarding command

Description

Adds glab orbit setup, a single command that walks a user through everything needed to make Orbit useful from their terminal:

1. Reachability check — calls GET /api/v4/orbit/status and routes errors through orbiterr.Translate, so feature-flag-off / 401 / 403 / 429 surface the same messages and exit codes as glab orbit remote status.
2. Skill install — fetches the orbit entry from the curated remote registry (registry.Get("orbit"), added in !3238 (merged)) and writes the SKILL.md + supporting files into .agents/skills/orbit/. Honors --global, --path, and the implicit repo-root default — same scope resolution as glab skills install.
3. Local CLI install — uses binarymgr.Runner.HandleInstall (the same code path as glab orbit local --install). Platform detection driven by local.Spec().NormalizeArch(...), so it auto-skips on platforms where the Orbit local binary isn't published (Windows today) without hard-coding runtime.GOOS.

Each step after reachability prompts before acting; --yes, --skip-skill, --skip-local, and --upgrade cover the non-interactive and re-fetch cases. --upgrade re-fetches the skill and routes the binary step through HandleUpdate instead of HandleInstall.

Why one command instead of three

The three primitives (orbit remote status, skills install orbit, orbit local --install) all already exist and are fine individually — but a new user shouldn't have to know that. setup composes them in the correct order (cheap reachability first, then skill, then binary download) and short-circuits cleanly when reachability fails, so users never download a binary or write a SKILL.md for an Orbit they can't reach.

Why not a separate glab orbit upgrade

Folded into --upgrade on the same command — the prompts and flow are identical to setup, only the defaults differ (always-yes, plus HandleUpdate instead of HandleInstall). One command, half the surface area to document and maintain.

Related Issues

Follow-up to !3238 (merged) (curated remote skill source — registered orbit as the first remote skill, which this command is the user-facing onboarding for).

Not tied to a specific work item — this rounds out the Orbit CLI surface area introduced across recent merges (!3235 (merged), !3237 (merged), !3238 (merged) for skills; the orbit remote/ and local/ subtrees for the orbit command itself).

How has this been tested?

• New setup package has unit tests covering: cobra wiring, status-only happy path, FF-off short-circuit (asserts ExitOrbitUnavailable), --path / --global / --skip-skill scope resolution, idempotent skill writes (with and without force), and the mutually-exclusive --global / --path flag pair.
• Updated internal/commands/orbit/orbit_test.go to assert setup is registered as a subcommand.
• go build ./..., go vet ./..., and go test ./internal/commands/orbit/... ./internal/commands/skills/... ./internal/binarymgr/... all pass locally.
• golangci-lint run ./internal/commands/orbit/setup/... reports 0 issues.
• Pre-push hooks (lychee, vale, markdownlint, build, check-generated, go-test, go-lint) all passed.
• Manually verified the help and example output via make gen-docs.

Screenshots (if appropriate):