Add the remaining pull mirror params to the API update allow list

What does this MR do and why?

PUT /projects/:id declares mirror_user_id, only_mirror_protected_branches, mirror_branch_regex and mirror_overwrites_diverged_branches, but its at_least_one_of list leaves them out. A request that sends only one of them answers 400 with ... are missing, at least one parameter must be provided, though the same value is applied beside any listed parameter.

mirror and mirror_trigger_builds, deprecated with them in favor of the pull mirroring API (PUT /projects/:id/mirror/pull), are already in the list: !223933 (merged) added mirror_trigger_builds for the same 400. This MR adds the other four to update_params_at_least_one_of, with request specs that send each one alone.

I saw the note there that these updates are soft-deprecated (!223933 (comment 3094119787)). They stay until v5 of the API, and the new route does not cover them all yet: it still carries route_setting :lifecycle, :experiment and always makes the caller the mirror user, with no mirror_user_id.

The one change a client sees: a body with only one of these four now gets the answer it would get with a listed parameter beside it, instead of that 400. Permissions do not change, as two new examples check: a user who cannot administer the project's mirror still has them dropped, and only an administrator can set mirror_user_id to another user.

show_default_award_emojis (CE) has the same gap, left to #348365, which is assigned.

I found this while working on gitlab-mcp-server.

What I ran (Ruby 3.3.11, PostgreSQL 17, Redis 7.2)

• GitLab EE 19.5.0 (gitlab/gitlab-ee:19.5.0-ee.0, Ultimate license): PUT /projects/:id with {"mirror_branch_regex": ""} alone answered the 400 above, and with "description": "probe" beside it answered 200 and cleared the stored regex.
• The new examples on master's code (e0f678adfc1c): 7 examples, 6 failures, the six new ones, each on the 400 above: the four that send one parameter alone, written before the fix, and the two permission ones. The mirror_trigger_builds example beside them passes.
• On this branch: ee/spec/requests/api/projects_spec.rb in full, 239 examples, 0 failures, 2 pending (two granular token examples of the audit events routes that need a top-level group); the CE example returns 400 when nothing sent still passes under EE.
• RuboCop on both files, scripts/lint/commit_linter.rb and the gitlab-dangerfiles commit linter on the commit, and gitlab:openapi:v3:check_docs report nothing.

References

Closes #637897

Related to #417081 (closed), the same 400 for mirror_trigger_builds.

Screenshots or screen recordings

Not applicable: no UI change.

How to set up and validate locally

1. On a Premium or Ultimate instance, set up pull mirroring on a project you own (Settings > Repository > Mirroring repositories, direction Pull).

2. Send one of the four parameters alone:

   curl --request PUT --header "PRIVATE-TOKEN: <your_token>" \
     --data "mirror_branch_regex=release/.*" \
     --url "http://gdk.test:3000/api/v4/projects/<project_id>"

3. On master the answer is the 400 above. On this branch it is 200, and GET /projects/<project_id>/mirror/pull returns "mirror_branch_regex": "release/.*".

I sent step 2 with an empty mirror_branch_regex to GitLab EE 19.5.0 and got that 400; the request specs in the block above send each of the four alone.

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.