Backport of 'Enable Orbit and Knowledge Graph feature flags by default'

What does this MR do and why?

Backport of !245620 (merged).

Enables the Orbit and Knowledge Graph feature flags by default. knowledge_graph, orbit_foundational_agent and orbit_mcp_command_tools graduate to beta, because wip and gitlab_com_derisk flags cannot be default_enabled: true. User-facing Orbit availability is now gated on the instance config knowledge_graph.enabled through Analytics::KnowledgeGraph.enabled_for?, so the UI stays hidden on instances where the Knowledge Graph service isn't wired up.

This is a ~"type::maintenance" change and not a bug fix, so the first checklist item is unticked. I believe we still need it in 19.2, because the flags have to be default-enabled for Orbit to reach GA on GitLab Dedicated, which cannot use non-default-enabled feature flags. I'm requesting a backport exception from the release managers and will link the request here. It shouldn't be merged until the exception is granted. Link: https://gitlab.slack.com/archives/C0B1081EDH9/p1785249879201909

The cherry-pick of efa8335 applied cleanly with no conflicts.

Verification on 19.2, click to expand

The +/- lines of the backport commit are byte-identical to efa8335 on master: 34 files, 305 insertions, 65 deletions, including the three flag renames and the two new files. A clean apply doesn't mean the result is correct on a branch this far behind master, so I also checked:

Check	Result
The 9 Analytics::KnowledgeGraph.{enabled_for?,accessible_for?,service_configured?} call sites under ee/app and ee/lib	Identical set to master, so no call site is left half-migrated
Residual direct Feature.enabled?(:knowledge_graph, ...) sites (ee/app/finders/ee/groups_finder.rb, ee/app/graphql/ee/types/group_type.rb, ee/app/helpers/dashboard/orbit_helper.rb, ee/app/policies/ee/group_policy.rb)	Identical set to master, which deliberately leaves these on the raw flag, so it isn't a backport gap
ee/config/feature_flags/** layout for every Orbit/KG flag	Identical to master. No stale wip/knowledge_graph.yml or gitlab_com_derisk/orbit_*.yml, and no reference to the old paths
Feature::Shared::TYPES on 19.2	beta is can_be_default_enabled: true, wip and gitlab_com_derisk are false, so the graduation is required here for the same reason as on master
Gitlab.config.knowledge_graph['enabled'] and Gitlab::Configs::MissingConfig, both used by the new Analytics::KnowledgeGraph	Both exist on 19.2
milestone: in the flag YAMLs	!245620 (merged) already sets the graduated flags to '19.2', so no adjustment was needed
ruby -c on the 28 changed .rb files, YAML.safe_load_file on the 6 flag YAMLs	Pass

bundle exec rubocop didn't run, the stable branch Gemfile.lock isn't installed locally, so CI covers it.

Related to #600633 Related to #583676 Related to #598922 Related to #602095

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.