Remove legacy vulnerability details page

What does this MR do and why?

The feature flag vulnerability_details_enrichment is a beta flag introduced in milestone 19.0, enabled by default, that rendered a redesigned vulnerability details page in place of the legacy page. The redesigned page has been the default experience for a while and has already been rolled out on GitLab.com. This MR removes the flag and deletes the legacy page, so the redesigned page becomes the only implementation.

Code changes

• It deletes config/feature_flags/beta/vulnerability_details_enrichment.yml and removes the push_frontend_feature_flag call from ee/app/controllers/projects/security/vulnerabilities_controller.rb.
• ee/app/assets/javascripts/vulnerabilities/vulnerabilities_init.js now always mounts the redesigned page, dropping the legacy branch, the flag check, and the router import. The root component is now a static import instead of a lazy import(), because the lazy chunk only existed so the legacy bundle did not ship the new page's code.
• It deletes the legacy Vue components under ee/app/assets/javascripts/vulnerabilities/components/ (vulnerability.vue, header.vue, footer.vue, vulnerability_details.vue, and their helpers) and their Jest specs. It also deletes the old integration-test mock file and two now-unused mutation mocks in ee/spec/frontend/vulnerabilities/mock_data.js, and removes a stale entry for a deleted file from .eslint_todo/tailwindcss-no-arbitrary-value.mjs.
• The redesigned page still shares history_entry.vue, history_comment.vue, vulnerability_actions_dropdown.vue, the from_haml.js adapter, header/vulnerability_actions.vue, and three Storybook stories. Their comments were reworded so they no longer refer to a legacy page, but there is no behaviour change.
• locale/gitlab.pot loses the strings that were used only by the legacy page.
• The docs page doc/user/application_security/vulnerabilities/_index.md gets a history entry saying the redesigned page is generally available in GitLab 19.5 and the flag is removed. It also drops the note that said the redesigned page was behind a flag.

Spec changes

• ee/spec/features/projects/security/vulnerability_details_spec.rb: before this MR, the redesigned page had only one smoke example. Every AI-actions scenario ran with the flag disabled, so it actually tested the legacy page.
  • What moved: the flag-disabled wrapper is gone, every scenario now runs against the redesigned page, and the layout check is a shared example every context runs. The spec now expects the redesigned page's "AI actions" label instead of the legacy "AI vulnerability management" label.
  • The no-AI check: the two contexts where AI actions must not appear, no Duo licence and a DAST finding, share one example. It waits for the page title, then checks that the "AI actions" dropdown and the standalone "Resolve with AI" button are absent. The old check looked for the "Explain with AI" item, which always passed because that item only exists inside the closed dropdown.
  • The stub: the no-licence context now stubs ::Ai::DuoWorkflow.duo_agent_platform_available? to false. The Explain action is gated on the Duo Agent Platform setting, which defaults to on, not on the licence. That context previously did not produce the state its name describes.
• ee/spec/features/projects/security/remediate_with_scanner_suggestion_spec.rb: It no longer disables the feature flag, and it opens the "Other actions" menu instead of the legacy "Resolutions" menu.
• ee/spec/frontend_integration/vulnerabilities/vulnerabilities_init_integration_spec.js: It now mounts the redesigned page from the real vulnerability_details_app_data payload fixture that the adapter unit tests already use, instead of a hand-written legacy mock. Its assertions target the redesigned page, checking the title heading, the sidebar status and severity sections, the description text, and the related issues. Its teardown uses unmountVueApp.
• qa/qa/ee/page/project/secure/vulnerability_details.rb (a page object in the QA end-to-end test suite under qa/): It drops the legacy view declarations and the enriched_details_page? branching that picked selectors per page, so every method now targets the redesigned page directly. resolve_this_vulnerability waits for the page root, then uses the standalone "Resolve with AI" button when it is present and the "AI actions" menu item otherwise. Status changes now go through the sidebar's Edit button.

References

• Related to https://gitlab.com/gitlab-org/gitlab/-/issues/608589
• Rollout issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/606953
• Epic: https://gitlab.com/groups/gitlab-org/-/epics/21907

Screenshots or screen recordings

There are no visible changes. The redesigned page was already the default experience, and this MR only removes the legacy implementation and the feature flag.

How to set up and validate locally

1. Open any vulnerability's details page in a project that has vulnerabilities. It needs no feature flag setup any more.
2. Check that the page renders with the header actions, the sidebar with its status and severity sections and their Edit actions, and the activity feed, with no console errors.
3. Optionally run the feature spec ee/spec/features/projects/security/vulnerability_details_spec.rb and the Jest specs under ee/spec/frontend/vulnerabilities/components/vulnerability_details_enrichment/.

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.