Fix flaky subgroup transfer feature spec

What does this MR do and why?

Fixes the master-broken failure in spec/features/projects/settings/user_transfers_a_project_spec.rb:58 (schedules an async transfer to a subgroup) tracked in gitlab-org/quality/analytics/ci-health-incidents#1252 (closed).

Failure:

expected: "transfer_scheduled"
     got: "ancestor_inherited"

Root cause: the example asserts project.project_namespace.reload.state right after expect(page).to have_current_path(edit_project_path(project)). The page is already on edit_project_path(project) before the transfer form is submitted, and ProjectsController#transfer redirects back to that same path, so the matcher is satisfied immediately and does not wait for the POST to finish. The DB is read while the request is still in flight, returning the default ancestor_inherited state.

The sibling example (schedules an async transfer and shows the transfer banner) does not race because it waits for the "scheduled for transfer" banner first.

Fix: wait for the transfer banner before reading the namespace state, mirroring the sibling example.

Introduced by !250913 (merged), which removed the groups_and_projects_async_transfer feature flag and rewrote this example.

References

• Incident: gitlab-org/quality/analytics/ci-health-incidents#1252 (closed)
• Causing MR: !250913 (merged)

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.