Correct the protected branches note on emptied push access

What does this MR do?

Corrects the note under the protection strategies on the protected branches page. It said that an Allowed to push and merge setting that is not configured does not restrict push access, which contradicts the permissions table above it. Clearing every selection on an existing rule refuses every push. A branch protected without selecting who can push gets Maintainers, the push_access_level default on the protected branches API page. The note now says both, and keeps its advice to set No one. It also renames the permissions table's "Default behavior" column, which gave the emptied state as the default, and drops "(not empty)" from the two strategy bullets.

The two states, and how we checked

flowchart LR
  A["Protect a branch without<br/>selecting who can push:<br/>API, group API,<br/>or the branch rules page"] --> B["AccessLevelParams<br/>adds Maintainer (40)"]
  B --> S["Maintainers"]
  S --> R1["Maintainer or Owner: accepted<br/>Developer: refused"]
  C["Empty the setting:<br/>clear every selection under<br/>Settings > Repository,<br/>or delete the last entry<br/>through the API"] --> Z["No push entries"]
  Z --> R2["Every push refused"]

• ProtectedRefs::AccessLevelParams, with its EE override, adds Maintainer when a request gives neither push_access_level nor an allowed_to_push entry. The API create endpoint and the branch rules create mutation both go through it.
• Clearing every selection in the protected branches table under Settings > Repository deletes each entry. With no push entry on any rule that matches the branch, the push check refuses every push. The table's "No one can push" holds for this state.

On GitLab 19.4.1 Ultimate, branches protected through the API with push_access_level left out or with allowed_to_push: [], and a branch created on the branch rules page, stored Maintainers. On each one, a Maintainer's git push was accepted and a Developer's was refused, the same as on an explicit Maintainers rule, while No one refused both. On master at 11fd11a5 (the linked files are unchanged at 683f41b0), request specs ran the same cases through the internal API that checks each push and got the same results, including for a rule created through the group API, and an Owner's push matched the Maintainer's on every branch. The same specs emptied a rule through the protected branches settings endpoint and through the API update endpoint, and the Owner, Maintainer and Developer pushes were then all refused.

Related issues

The note and the table were added in !199463 (merged).

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change. The assistant also read each linked code path at master, ran the pushes and request specs described here on a GitLab 19.4.1 test instance and in a master test environment, and ran the project's Vale and markdownlint configuration on the changed page.