Draft: Fence project settings writes behind the policy evaluation

What does this MR do and why?

Evaluates a project settings write against the settings enforcement policies before it reaches the database. Govern::PolicyEngine::SettingsFence runs in the validate! step of Projects::UpdateService. An enforce-mode policy refuses the write with its authored message, through the same path as every other validation error. A warn-mode policy lets the write through, and the controllers show its message as a flash.

The fence reacts only to the settings the write changes, so one noncompliant column cannot freeze the whole settings page. Noncompliance elsewhere belongs to the periodic check of !261561. An undecidable evaluation fails open and reports that it did, because failing closed would couple every settings write to store availability.

ProposedProjectSettings maps the raw update params onto the catalog keys. It reads them unfiltered on purpose: a strong-parameter slice must never hide a governed key from the evaluation.

The code comes from the prototype in !259574, now with request and feature specs. No changelog entry, because security_policies_v2 defaults to off.

Merge plan (nested = depends on parent, siblings = parallel)

• !261560 (merged) evaluation service
  • !261838 settings fence (this MR)
  • !261561 drift workers
  • !261562 conflict check
    • !261837 set_setting write-back
      • !264545 cross-trigger E2E (also needs fence, drift workers)
• !262405 effective archived state

The request spec here covers the settings-change trigger alone. The end-to-end spec that drives all three triggers in one run needs the drift workers and the write-back executor as well, so it waits in !264545 and merges once those land (https://gitlab.com/gitlab-org/gitlab/-/work_items/635669).

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/630156
• Epic: https://gitlab.com/groups/gitlab-org/-/work_items/23462

Screenshots or screen recordings

Backend-only change. The warn flash and the refusal alert appear in the standard settings UI.

Before	After

How to set up and validate locally

1. Create an enforce-mode settings policy with a setting_validation rule and a block action with a message.
2. In the project's settings UI, change the governed setting away from the expected value and save. The save fails with the authored message.
3. Switch the policy to warn mode and save again. The change saves, and the message appears as a warning.

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.