Fix flaky protected branches code owner feature specs

What does this MR do and why?

Fixes and un-quarantines the two ee/spec/features/protected_branches_spec.rb "can create new protected branch with code owner ..." examples.

Closes https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/44329

Root cause

The form was never submitted (no POST /-/protected_branches in failing jobs). Reproduced locally (~1 in 3 runs) with JS instrumentation and a chromedriver --verbose log:

1. After picking "No one", the EE multi-select access dropdown stays open and covers the next toggle. chromedriver's pre-click visibility check fails, so it scrolls the settings container to centre the toggle. How far it scrolls depends on the height of the open menu, i.e. on whether the users/groups/deploy-keys responses had already arrived. In the unlucky case the Protect button ends up exactly on the bottom edge of the 1366×625 viewport (y=624..656).
2. chromedriver treats such a button as in view, but elementFromPoint at the click location returns div.panel-content (the button is clipped by the scroll container) → element click intercepted.
3. Capybara rescues the error, calls scroll_to_center and reloads the element via first(:link_or_button, 'Protect'). first does not use the exact-first :smart matching that find uses, so the substring locator also matches the settings-section chevron button with aria-label="Collapse Protected branches" (Capybara.enable_aria_label = true), and that button comes first in document order.
4. The retried click hits the chevron, the "Protected branches" section collapses, no request is sent, and find_by_name(...) returns nil. This matches the CI failure screenshots (section collapsed).

The correlation with vue3_migrate_repo_settings is timing only: the @vue/compat bundle loads the dropdown contents on a slightly different schedule, which made the "menu open + data loaded" combination far more likely. Section heights are identical in both builds; @vue/compat is not dropping any listener. The previous fix attempts (!252429 (closed), !252527 (merged)) added waits after a click that never reached the form.

Fix

• Scope access-level selection and the submit click to the form (within(container)), so the chevron can never be matched.
• Close the EE multi-select access dropdown with Esc after picking an option so the open menu never overlaps the form and never triggers chromedriver's extra scrolling.
• scroll_to(protect_button, align: :center) before clicking, so chromedriver never hits the viewport-edge intercept.
• Remove the quarantine: metadata.

Local verification: 6/6 green runs of the three examples after the fix (identical scroll offsets every run) vs ~1 failure per 3 runs before.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.