Draft: [skip ci] Drive the settings enforcement triggers end to end in one run

What does this merge request do and why?

Drives all three settings enforcement triggers in one run: a created project gets the required value written onto it, the periodic check corrects a project that drifted out of band, and one setting stays governed across the three triggers at once.

These five examples used to live with the settings fence. The enforcement merge requests were then rearranged so that the fence, the drift workers and the conflict check no longer wait on one another and can merge in parallel, and these examples were the one piece that could not follow: they need the fence, the drift workers and the write-back executor present at the same time, which no single merge request in that arrangement provides. The four examples covering the settings-change trigger alone stayed with the fence.

Do not merge yet. This one is last on purpose. It goes green once the settings fence, the drift workers and the write-back executor have all merged.

Then rebase on master, remove the [skip ci] from the title, and start a pipeline. The spec was verified locally against the three branches merged together: 9 examples, 0 failures.

It targets the fence branch so the diff shows only the restored examples. GitLab retargets it as the stack merges.

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

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

References

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

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.