feat(orbit): route glab orbit through the orbit-cli binary

Description

glab orbit <command> now runs the managed Orbit binary. glab forwards your arguments to the binary and adds two things of its own: it manages the binary (download and update), and it injects your GitLab credential for remote commands. The binary owns the commands, so the Orbit team ships new ones in a binary release, not a glab change.

• glab orbit remote query ./q.json runs orbit remote query ./q.json with your credential.
• glab orbit local index and glab orbit version run the binary with no credential.

Related Issues

Relates to gitlab-org/orbit/knowledge-graph#1157

Backwards compatibility

glab orbit sends all arguments to the orbit binary. remote, local, setup, and version still work. Config keys (orbit_local_*) and the GLAB_ORBIT_LOCAL_BINARY_PATH variable do not change. These change:

• glab orbit local version now fails. Use glab orbit version.
• The --hostname flag is removed. glab uses the default host.
• glab does not force a binary upgrade. Run glab orbit --update to update.
• All seven Orbit MCP tools are removed. glab mcp serve exposes no Orbit surface. This is intentional. The passthrough forwards side-effecting commands (setup, local index, --install), so it must not be auto-invokable by an MCP client. Re-adding it is not simple: the executor uses syscall.Exec, so an MCP-invokable passthrough would replace the running glab mcp serve process with the orbit binary.
• Shell completion past glab orbit is removed. The binary owns the subcommands.
• The --jq flag on the remote commands is removed. Pipe the binary output to jq instead.
• The orbiterr exit codes 1 to 5 (feature flag off, 401, 403, rate limited) are removed. The exit code now comes from the binary, unmapped.
• glab orbit setup changes meaning. It now writes per-assistant instruction files through the binary and needs a positional assistant (for example, glab orbit setup claude). It no longer runs glab's dedicated /api/v4/orbit/status reachability preflight or installs the curated skill. The 404 hint (the knowledge_graph feature flag is off) is not lost: orbit-cli prints the same hint, with the same exit code, when a remote command hits a 404. The curated skill is tracked as a follow-up.
• An existing CI job with a managed install older than 0.103.0 now hard-errors until ORBIT_LOCAL_AUTO_DOWNLOAD=true is set. The version floor triggers a re-download, which requires consent. Before this change, the stale binary kept running.

How has this been tested?

go build, go vet, gofmt, and the orbit and binarymgr unit tests pass. Four internal/config tests fail on main too; they are local environment artifacts. Live against gitlab.com: a clean install downloads the latest orbit-cli, remote status and remote query authenticate, and local and version run with no credential.

Screenshots (if appropriate):

Not applicable.

Details for reviewers

• Passthrough: glab orbit uses DisableFlagParsing, splits its own flags (--install, --update, --yes), and forwards the rest verbatim. --help alone shows glab's help; otherwise the binary answers it.
• Auth, remote only: when the first token is remote, glab resolves the credential via AuthSource().Header() and injects ORBIT_API_BASE_URL / ORBIT_AUTH_HEADER_NAME / ORBIT_AUTH_HEADER_VALUE. Refresh and keyring stay in glab.
• Binary: managed through internal/binarymgr as the orbit-cli package; the download is unauthenticated.
• Config: unchanged — keeps the existing orbit_local_* keys and GLAB_ORBIT_LOCAL_BINARY_PATH variable, so no config churn.
• Removed: the remote/local/setup wrappers and orbiterr. The binary owns them, and it is still installed automatically before any command runs.