Seed a group in QA setup to skip SM admin onboarding

What does this MR do and why?

Fixes the e2e-test-on-omnibus failures where browser UI tests fail with:

QA::Page::Validatable::PageValidationError:
  super-sidebar did not appear on QA::Page::Main::Menu as expected

Root cause

!239674 (merged) removed the self_managed_welcome_onboarding feature flag (merged 2026-06-09 15:01 UTC), making the self-managed admin welcome flow permanently enabled. On a fresh instance with no groups, SessionsController now redirects the admin's sign-in to /admin/registrations/groups/new, which renders with the minimal layout (no super sidebar).

Every E2E omnibus job starts with a brand-new instance (no groups), so Flow::Login.sign_in_as_admin lands on the onboarding page and Page::Main::Menu.validate_elements_present! times out after 60s waiting for super-sidebar. Failures started 2026-06-09 19:11 UTC, the first omnibus pipelines after the flag removal.

The redirect is gated on a single condition in SessionsController#should_redirect_to_sm_onboarding?: for an admin on a non-dedicated instance, it fires whenever !Group.exists?. That is a system-wide check — it is not scoped to the user, organisation, or membership — so as soon as any group exists anywhere on the instance, the redirect stops for every admin.

Fix

Create one group before any admin signs in through the UI, so Group.exists? is already true the first time the onboarding check runs.

QA::CE::Strategy#perform_before_hooks now fabricates the e2e sandbox group via the API (ensure_initial_group_exists!), right after the admin API client is initialised.

Doing this via the API rather than the UI matters for two reasons:

1. It runs before any spec, so no admin sign-in ever reaches the onboarding redirect.
2. The first lazy Resource::Sandbox fabrication itself takes the UI path (Sandbox#fabricate! calls Flow::Login.sign_in_unless_signed_in), so without this it would hit the same redirect.

The helper is a no-op on live environments (which already have groups and use SaaS onboarding) and when no admin API client is available, and it logs a warning rather than failing the suite if fabrication errors.

Fixes:

• https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/43138
• https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/43139
• https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/43140
• https://gitlab.com/gitlab-org/quality/test-failure-issues/-/work_items/43141

Related

• Flag removal: !239674 (merged)
• Feature introduction: !228898 (merged) (redirect), !233114 (merged) / !233115 (merged) (Step 2 profile page)

How to set up and validate locally

1. Put a GDK into the failing state: a fresh instance with no groups, behaving as self-managed.

   bundle exec rails runner "Project.delete_all; Group.delete_all"
   export GITLAB_SIMULATE_SAAS=0

2. Run any admin-login E2E spec against it, for example:

   cd qa
   bundle exec rspec qa/specs/features/browser_ui/14_analytics/service_ping_disabled_spec.rb

3. Confirm the before-hooks log shows the sandbox group being fabricated, the admin sign-in lands on the dashboard (no /admin/registrations redirect), and menu validation passes.

MR acceptance checklist

This MR only changes the E2E test framework (qa/); no production code changes.