feat(orbit-cli): read orbit status from GraphQL serviceStatus first

What does this MR do and why?

orbit status and the setup GitLab check now read service health from GitLab GraphQL. They fall back to the deprecated REST status endpoint only on GitLab without it, so we can remove that endpoint.

Area	Before	After
orbit status	REST orbit/status	GraphQL orbit.serviceStatus, REST on older GitLab
Setup GitLab check with no origin	REST orbit/status	Same as orbit status
Graph status when Orbit is off for a group	REST orbit/status for the reason	GraphQL orbit.serviceStatus for the reason
REST status code	remote/status.rs, client.rs	remote/legacy/status.rs
Vendored GitLab GraphQL schema	Job 17448481030	Job 17517691030, which has serviceStatus

Related Issues

Relates to #263

Testing

cargo test -p orbit-cli passes, with 323 tests. On gitlab.com, orbit status sends one GraphQL request. Behind a proxy that rejects GraphQL, it sends one GraphQL request and then one REST request.

Performance Analysis

On GitLab with serviceStatus, the request count does not change. On older GitLab, the first call sends one more request.

• This merge request does not introduce any performance regression. If a performance regression is expected, explain why.

Agent context: long-form analysis, file-by-file walkthroughs, profiler output, alternatives considered

• Builds on !3085 (merged), which is merged, and uses its fallback pattern. OrbitClient::graphql returns no response when GitLab rejects the query as unknown schema. Since 1cee07c7, that includes undefinedDirective. The command then calls legacy::run_status.
• A null serviceStatus means that the user has no Orbit, so the command exits 2 and does not fall back.
• Graph status keeps exit 4 ("not turned on for the group") unless serviceStatus says that the user has no Orbit.