Draft: Detect and log conflicting setting demands per evaluation

What does this MR do and why?

Two enforce policies can demand different values for the same setting of one project. Once the write-the-setting executor exists, each evaluation would write one value and the next would write the other, so the setting would alternate between runs. Design agreed to do nothing and log for the experiment (https://gitlab.com/groups/gitlab-org/-/work_items/23462#note_3979599650).

This MR adds the detection. Govern::PolicyEngine::ConflictedSettings reads the setting_validation rules of every enforce policy that matched with a write action, and names the settings that collect more than one demanded value. The check runs per evaluation, because two policies without overlap at save time can overlap later. The decision processor logs each conflict and passes the conflicted settings to every executor, so the coming write executor of https://gitlab.com/gitlab-org/gitlab/-/work_items/630155 can refuse those writes while the other settings proceed.

Still open on the issue, and deferred until the write executor exists: an audit event that names the policies and demanded values, and recording the conflict on the evaluation for the UI.

The code comes from the prototype in !259574, now with 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
  • !261561 drift workers
  • !261562 conflict check (this MR)
    • !261837 set_setting write-back
      • !264545 cross-trigger E2E (also needs fence, drift workers)
• !262405 effective archived state

References

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

Screenshots or screen recordings

Backend-only change, no UI.

Before	After

How to set up and validate locally

1. Enable the experiment as in the evaluation service MR.
2. Create two enforce policies on the project_created trigger whose setting_validation rules demand opposite values for request_access_enabled, both with a set_setting action.
3. Create a project both policies cover, then check the application log for a govern_policy_conflict event naming the setting.

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.