Make the Orbit API docs match the code

What does this MR do?

The Orbit REST API page did not match the code on master. This MR fixes the facts and adds the request attributes and errors that were missing.

We ran each changed claim against a GDK on master with Orbit main. We regenerated the OpenAPI definition, the GraphQL reference, and the introspection schema from the code.

Area	Change
Status	Orbit is generally available since GitLab 19.5, so the Beta notes and the beta route lifecycle are gone. Experiment endpoints keep their status.
Page	Offering lists GitLab Self-Managed and GitLab Dedicated. The intro names queries, search, context, and skills. A new section states the rate limits.
Endpoint status	The status table from !265594 (merged) lists only routes that still exist.
Run a query	New attribute table, and an error table for 400, 402, 403, 404, 422, 429, 502, and 504. Query language and query examples move to the Orbit docs, and this page links there.
Run a named query	New attribute table and cURL example. The section says that Query.orbit.queryTemplates lists the named queries.
Search (grep)	Experiment status, the use_global_search token permission, the 400 and 429 cases, and the branch reference shape.
Context	Version 1.3.0, the test report and discussion permissions, and fake example data.
Skills	The name rule, 304 for the list, and 400 for a .. path segment.
GraphQL	Group.orbit status fields give the null rule and the rate limit. Fields that resolve once say so.
Internal API	All endpoints need Workhorse and a JWT. project_id takes an ID or a path. The archive audit event names the Orbit indexer as author. The page states the revisions and per-file diff limits.
Setup page	The menu name is GitLab Orbit, the trial history is GitLab 19.6, and the front matter names the Orbit group.
Other pages	The MCP clients page drops a local server example that does not exist. Links go to the current Orbit pages. The trial audit event milestone and the promo flag description match the code.

Out of scope: the admin namespaces API gets a rename first, so this MR does not document it.

Related issues

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

Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/633612

The Orbit user docs get the same fixes in gitlab-org/orbit/knowledge-graph!3145 (merged).

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.