Add an instance setting to enable Orbit in DAP by default

What does this MR do and why?

Adds an instance setting that enables Orbit in GitLab Duo by default on GitLab Self-Managed and GitLab Dedicated. On GitLab.com, the setting is not shown and the fallback stays off. Explicit user choices continue to take precedence. The effective GraphQL response and preferences form handling keep inherited settings consistent without turning unrelated preference saves into opt-outs.

References

Relates to gitlab-org/orbit/knowledge-graph#1319 (closed)

Screenshots or screen recordings

Admin > Orbit on GitLab Self-Managed

The existing After screenshot needs retaking because the new checkbox should now be selected by default. The Before screenshot remains the baseline without this setting.

Before	After, needs retaking

User preferences for a user who never saved an Orbit preference (orbit_settings is {})

These screenshots remain valid. The first shows an administrator turning the instance default off. The second shows the default behavior on GitLab Self-Managed and GitLab Dedicated.

Administrator turned the instance default off	Self-Managed and Dedicated default on

A user who explicitly turned Orbit off stays off when the instance default is on:

How to set up and validate locally

1. Run the focused backend specs:

   bin/rspec ee/spec/models/user_preference_spec.rb ee/spec/models/ai/orbit/settings_spec.rb ee/spec/controllers/ee/profiles/preferences_controller_spec.rb ee/spec/views/profiles/preferences/show.html.haml_spec.rb ee/spec/requests/api/graphql/mutations/user_preferences/update_spec.rb

2. Run the frontend component specs:

   yarn jest ee/spec/frontend/ai/duo_agentic_chat/components/orbit_toggle_spec.js ee/spec/frontend/ai/duo_agentic_chat/components/duo_agentic_chat_state_manager_light_spec.js --runInBand

Agent context

The setting uses the existing ApplicationSetting#orbit_settings JSONB column, so no migration is required. UserPreference#orbit_enabled falls back to the instance default only when the enabled key is absent. The fallback is on for GitLab Self-Managed and GitLab Dedicated, and always off on GitLab.com. GraphQL returns all five effective Orbit values, while persistence continues to merge raw JSON. The preferences controller permits the five checkbox values only when the submitted values differ from the current effective values.

For runtime Orbit functionality, the fallback is reached from Ai::Orbit::Settings.subsetting_enabled? only after the existing platform availability and feature gates. License or namespace enrollment checks also remain in the existing availability path. This MR does not add a second availability gate. The GitLab team member shortcut remains unchanged.

Changing an Orbit toggle in agentic chat is a deliberate user choice, like changing any Orbit checkbox in Preferences. This interaction persists the full explicit Orbit state. Only an untouched whole-form Preferences save preserves inheritance from the instance default.

The reduced-presentation DAP chat client previously sent useOrbit: false without loading the effective preference. It now loads the effective GraphQL value before building workflow payloads. Gitlab::CurrentSettings already uses a 60-second in-memory cache, so this MR does not add another cache layer.

The Knowledge Graph settings registry exposes the new value through the Admin Orbit form, application settings API, and gitlab:orbit:info. This MR also updates the JSON schema, OpenAPI output, product documentation, and gettext catalog. Admin > Orbit hides the setting on GitLab.com.

MR acceptance checklist

Evaluated against the MR acceptance checklist. No migration is introduced. The instance setting defaults on for GitLab Self-Managed and GitLab Dedicated, is not applicable on GitLab.com, and remains subject to the existing Orbit availability, licensing, and namespace enrollment gates.