Remove groups_and_projects_async_transfer feature flag

What does this MR do and why?

Removes the groups_and_projects_async_transfer feature flag and makes asynchronous group/project transfers the unconditional default behavior.

The feature flag was introduced in GitLab 18.11 to gate async background-job transfers for groups and projects. The epic (gitlab-org#20521 (closed)) is now closed and the feature has been fully rolled out (#594575 (closed)), so the flag is no longer needed.

Changes:

• Remove all Feature.enabled?(:groups_and_projects_async_transfer, ...) checks from:
  • app/graphql/mutations/groups/transfer.rb
  • app/graphql/mutations/projects/transfer.rb
  • app/controllers/groups_controller.rb
  • app/controllers/projects_controller.rb
  • lib/api/groups.rb
  • lib/api/projects.rb
• Delete the synchronous fallback code paths (execute_sync_transfer helpers, disable_transfer_query_limiting before_action)
• Delete config/feature_flags/beta/groups_and_projects_async_transfer.yml
• Update doc/user/group/manage.md and doc/user/project/working_with_projects.md to remove the feature-flag caveat from the history note
• Update all RSpec specs to remove the disabled-flag contexts and keep only the async transfer test paths

References

• Closes #617846 (closed)
• Feature flag rollout: #594575 (closed)
• Epic: gitlab-org#20521 (closed)

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

1. Verify no references to groups_and_projects_async_transfer remain in the codebase
2. Transfer a group or project via the UI, REST API, or GraphQL -- it should always be scheduled as a background job (state transitions to transfer_scheduled)

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.