Enable MCP server by default for new groups

What does this MR do and why?

Makes the MCP server setting default to on for newly created top-level groups.

This was the intended behavior as of a few milestones ago, but wires got crossed and after the backfill migration ran for existing groups the default for new groups was never changed to true

namespace_settings.mcp_server_enabled had no database default, and Group#mcp_server_enabled? reads a blank value as off. So, before this change, a top-level group created today is created with MCP switched off, while a self-managed instance installed today has MCP on (application_settings already defaults the setting to true).

With the MCP server going GA in 19.5, new groups should receive it the way they receive any other GA feature.

Scope: this only affects rows created from now on. Existing groups keep whatever value they have. Bringing existing groups and instances to an "on" state will happen in follow-on MRs.

Because application code writes this column, the default is changed following the SafelyChangeColumnDefault process: the model declares a matching Rails attribute default so the written value never comes from a stale schema cache during a deploy. The columns_changing_default entry should be removed in 19.6.

Migration

change_column_default on a nullable boolean is a catalog-only change — no table rewrite, no backfill. namespace_settings is not on the high-traffic list.

== 20260921120000 ChangeNamespaceSettingsMcpServerEnabledDefaultToTrue: migrating ==
-- change_column_default(:namespace_settings, :mcp_server_enabled, {:from=>nil, :to=>true})

Spec changes

Four existing specs assumed a freshly created group had MCP off. They now set the value explicitly so they keep testing what they claim:

• spec/models/group_spec.rb — group_nil in .with_mcp_server_enabled is now explicitly nil
• count_root_groups_mcp_server_enabled_metric_spec.rb — the NULL context sets nil explicitly
• ee/spec/services/groups/update_service_spec.rb — the "changes" context starts from false
• ee/spec/requests/api/mcp/base_spec.rb — the :no_enabled_namespace denial case uses :with_mcp_server_disabled

References

• Open question raised in https://gitlab.com/gitlab-org/gitlab/-/work_items/630175 (confidential): whether to also turn the setting on for groups and instances that already exist. That part needs Legal sign-off; this MR deliberately does not do it.
• Customer report that surfaced the setting being off unexpectedly: #600594 (closed)
• Original spec for the setting: #590729 (closed)

Screenshots or screen recordings

No UI change. The MCP client access checkbox in Settings > General > Permissions and group features renders from the stored value, so it is simply pre-selected for newly created groups.

Before	After
New top-level group is created with Allow connection to GitLab cleared	New top-level group is created with Allow connection to GitLab selected

How to set up and validate locally

1. On master: In the UI, create a top-level group, then go to Settings > General > Permissions and group features and confirm Allow connection to GitLab is not selected.
2. On this branch: In the UI, create a top-level group, then go to Settings > General > Permissions and group features and confirm Allow connection to GitLab is already selected.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Notes for reviewers:

• Database review required (migration + schema change).
• Local RuboCop, RSpec and Danger could not be run in the authoring environment: the branch is based on current master, whose Gemfile.lock pins gems that are not installed locally (gitaly-19.4.0, gitlab_query_language-0.38.0). The DB-related pre-push hooks (db-schema-changes, db-migration-checksum, db-migration-timestamp, db-migration-name-collisions) did run and pass. Please confirm the pipeline is green before merging.
• db/structure.sql was edited by hand rather than regenerated, for the same reason. The change is the single expected line (mcp_server_enabled boolean DEFAULT true,); the db:check-schema job will verify it.