fix: Turn software_development_flow_registry ff to default_enabled: true

What does this MR do and why?

This MR sets default_enabled: true for the software_development_flow_registry feature flag.

GitLab.com has had the flag on since 2026-08-06. Self-managed instances ship with it off, so they stay on the legacy software development flow. After this change, self-managed instances use the flow registry based software_development/v1 flow. IDE extensions that cannot run v1 fall back to the legacy flow.

Should be made the same milestone as announcement here: !260667 (merged)

Why the default flips before the legacy code is removed

The IDE extension picks the flow from this flag. With the flag off, it asks for the legacy flow. If we remove the legacy flow from the AI Gateway first, every self-managed instance still on the default breaks. Extensions that cannot run v1 fall back to the legacy flow, so the flip itself breaks no client.

These versions cannot run v1:

Client	Last version without v1	First version with v1
gitlab-lsp and Duo CLI	8.104.0	8.105.0
VS Code	6.84.1	6.85.0
JetBrains	3.39.0	3.40.0
Visual Studio	0.78.0	0.79.0

References

• Deprecation plan: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#2456 (closed)
• Flag rollout: #600944 (closed)
• Feature issue: #600848 (closed)
• Language server milestone, set after this merges: gitlab-org/editor-extensions/gitlab-lsp#2511 (closed)

Screenshots or screen recordings

Not applicable. This MR has no UI change.

How to set up and validate locally

1. In a Rails console, remove any local gate for the flag with Feature.remove(:software_development_flow_registry). An existing gate takes precedence over the default.
2. Run Feature.enabled?(:software_development_flow_registry, User.first). It returns true.

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.