Add vue3_migrate_pages flag for GitLab Pages and Pages domains entrypoints

What does this MR do and why?

Adds the vue3_migrate_pages feature flag (beta, disabled by default) and five vue3_migration.yml files, one per GitLab Pages and Pages domains entrypoint:

Entrypoint	Vue apps / modules mounted
pages/projects/pages	~/search_settings (guarded no-op — see note below)
pages/projects/pages/new	~/gitlab_pages/new (initVueApp)
pages/projects/pages/show	~/gitlab_pages/show (initVueApp)
pages/projects/pages_domains/new	~/pages/projects/pages_domains/form (initToggle — no Vue app)
pages/projects/pages_domains/show	~/pages/projects/pages_domains/form (initToggle — no Vue app)

With status: rollout, the bundler emits both a Vue 2 chunk and a .vue3 chunk per entrypoint, and Gitlab::Vue3Migration.entrypoint_for picks per request using current_user as the actor, so the rollout can ramp gradually and roll back instantly.

The flag ships disabled (default_enabled: false), so merging this changes nothing for users.

EE check: No shadow directories exist under ee/app/assets/javascripts/pages/projects/pages or pages_domains, so no EE yml counterparts are required by spec/lib/gitlab/vue3_migration_files_spec.rb.

Shared module note: pages_domains/form.js is a shared module imported by both new/ and show/ — it is not itself an entrypoint, so no yml is placed next to it.

SearchSettings note: pages/projects/pages/index.js calls initSearchSettings(), but the Pages views use the project layout (not project_settings), so the .js-search-settings-app mount element does not exist and the init is a guarded no-op (if (el)). The SearchSettings Vue app never actually mounts on these routes, so it carries no Vue 3 migration risk here. All remaining entrypoints were verified locally (see checklist below).

Flag ramp-up and the status: migrated cleanup are tracked as follow-ups on the rollout issue.

References

• Rollout issue: #627732
• Migration issue / agent work plan: #608113 (closed)
• Epic: gitlab-org#23090
• Migration docs: https://docs.gitlab.com/development/fe_guide/vue3_migration/

Screenshots or screen recordings

No UI changes — the flag ships disabled.

How to set up and validate locally

Note: the Pages routes are legacy routes without the /-/ prefix, e.g. /<namespace>/<project>/pages.

1. Enable GitLab Pages in the GDK (gitlab_pages: enabled: true in gdk.yml, then gdk reconfigure && gdk restart) and set up a project with a working Pages deployment (e.g. the pages/plain-html template with a docker runner).
2. Enable the flag in the Rails console:

   Feature.enable(:vue3_migrate_pages)

3. Restart Vite (it builds its page entry map at startup):

   gdk restart vite

4. Verify a page is on Vue 3 with:

   [...document.querySelectorAll('[data-gitlab-vue3-app]')].map((el) => el.dataset.gitlabVue3App)

Pages settings (/<project>/pages):

• Page loads with no console errors
• Search settings: not testable on this route — the SearchSettings app never mounts here (no .js-search-settings-app element in the project layout; initSearchSettings is a guarded no-op)

Pages new (/<project>/pages/new):

• Page loads with no console errors
• New Pages deployment form renders and submits correctly

Pages show (/<project>/pages):

• Page loads with no console errors
• Pages deployment details render correctly (GitlabPagesEditRoot mounted as Vue 3)

Pages domains new (/<project>/pages/domains/new):

• Page loads with no console errors
• SSL toggle works (show/hide certificate fields; requires Let's Encrypt enabled in admin settings)
• Form submits and creates the domain

Pages domains show (/<project>/pages/domains/:domain):

• Page loads with no console errors
• SSL toggle works correctly

Screenshots

Pages show	Pages new	Pages domains new	Pages domains show

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.