Set SHA requirement to false on group creation if ancestor is not locked

What does this MR do and why?

In GitLab 19.2, the require_sha_for_merge setting was introduced and new groups were given a default value of true. This meant that any group created after upgrading to 19.2 would require a commit sha parameter on all merge request API calls.

This MR changes the default value for require_sha_for_merge on new group creation from true to false, unless the setting is locked by the instance or an ancestor group (via lock_require_sha_for_merge). When the setting is locked, the new group inherits the locked value as before.

Before this change: New groups created in GitLab 19.2+ always had require_sha_for_merge = true (unless the setting was locked to false by an ancestor or the instance).

After this change: New groups created in GitLab 19.4+ have require_sha_for_merge = false by default, unless the setting is locked by the instance or an ancestor group.

This reduces the risk of unintentional breakage for users who upgrade to 19.2+ and create new groups without being aware of the new setting.

References

• Original feature MR: !244421 (merged)
• Group and instance settings UI: !243465 (merged)
• RFH gitlab-com/request-for-help#5229+

Screenshots or screen recordings

No UI changes.

Before	After
New groups created in 19.2+ had require_sha_for_merge = true by default	New groups created in 19.4+ have require_sha_for_merge = false by default (unless locked by ancestor or instance)

How to set up and validate locally

1. Start a local GDK instance.
2. Create a new group via the UI or API.
3. Check the group's namespace settings: NamespaceSetting.find_by(namespace_id: <group_id>).require_sha_for_merge — it should be false.
4. Lock the setting at the instance level (lock_require_sha_for_merge = true) and create another group — the new group should inherit the locked value.
5. Lock the setting at a parent group level and create a subgroup — the subgroup should inherit the locked value.

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.