Validate CSP namespace belongs to the setting's organization

What does this MR do?

Security::PolicySetting (Centralized Security Policy settings) had no validation that csp_namespace belongs to the same organization as the setting itself. The admin API (API::Admin::Security::CompliancePolicySettings) resolves the setting to the instance's default organization and passes csp_namespace_id straight through with no boundary check, so on a multi-organization instance an admin could point one organization's CSP at a group in a different organization — meaning that group's policies and compliance frameworks would be centrally managed by an unrelated organization.

This adds a model validation: csp_namespace.organization_id must equal organization_id whenever csp_namespace_id is being assigned.

Considered and dropped: also hard-blocking any csp_namespace_id assignment while on GitLab.com (CSP is already functionally disabled there via csp_enabled?'s gitlab_com_subscription? check). Dropped because ee/spec/models/security/policy_setting_spec.rb already has a test (#csp_enabled? ... when on GitLab.com) that intentionally exercises "namespace is set, but disabled at read-time on .com" as the expected behavior — a persistence-level block would contradict that already-encoded design and is a bigger, separate discussion than this fix.

Production impact today: none. GitLab.com is single-organization, so this closes a gap that only becomes exploitable on self-managed/Dedicated once multi-organization ships broadly.

References

Relates to https://gitlab.com/gitlab-com/gl-infra/tenant-scale/organizations/organizations-feature-parity/-/work_items/102 (finding "CSP namespace can be set to a group in a different organization")

How to test

bundle exec rspec ee/spec/models/security/policy_setting_spec.rb ee/spec/requests/api/admin/security/compliance_policy_settings_spec.rb