Add dependency firewall namespace setting

What does this MR do and why?

This MR adds a setting for top level groups to enable the dependency firewall functionality and dashboard.

This MR (part 1 of 3) adds the storage layer for the setting only — the dependency_firewall_enabled boolean column on namespace_settings (default false), its model validation, and specs. Nothing reads or writes it yet. It's split this way to keep each MR small and reviewable.

The plan moving forward for an idea of how this might work (not all details set in stone):

MR2 — Settings UI (write path)

• Adds a toggle to Group Settings → General (or a new Secure section), rendered only for top-level groups and gated behind the dependency_firewall_phase1 feature flag and the licensed feature check.
• Permits the dependency_firewall_enabled param in the group settings controller.
• Enforces "top-level group only" + authorization at the service layer via NamespaceSettings::AssignAttributesService#validate_settings_param_for_root_group(param_key: :dependency_firewall_enabled, user_policy: :admin_group) — reusing the standard group-admin permission, no new ability.
• Anyone who can modify top-level group settings can toggle it.

MR3 — Enforcement gating

• Introduces a single centralized predicate, Namespace#dependency_firewall_enabled?, which resolves root_ancestor and reads the setting — so subgroups and projects inherit the top-level group's value without callers duplicating root-resolution logic.
• Wires this predicate into Security::DependencyFirewall::EnforcementService#execute, alongside the existing feature-flag and license checks, so the firewall only enforces when the top-level group has enabled it.

Choice of using a dedicated column

There does exist the security_policies jsonb on the namespace_settings (shared with application settings, schema named application_setting_security_policies). While this does have a dependency firewall related field in it currently, this schema only holds integer limits right now. So it did not feel like the right place for a plain boolean namespace toggle. The more conventional approach seems to be adding a dedicated column, which is probably better for the later enforcement related reads.

References

https://gitlab.com/gitlab-org/gitlab/-/work_items/604178

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. run the migration
2. in rails console, confirm the new namespace setting is present and set to false (something like Namespace.first.namespace_settings.dependency_firewall_enable)

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.