Migrate the vulnerability details page to vue3

What does this MR do and why?

Migrate the vulnerability details page to vue3

Adds all the necessary feature flags and ceremony to set the page up for the migration.

Also fixes an issue that was discovered while testing the page with vue3 enables.

References

Screenshots or screen recordings

These recordings cover the vulnerability details page across all four combinations of the two feature flags, vue3_migrate_vulnerability_details and vulnerability_details_enrichment, plus the new-vulnerability form fix and the dependency-path drawer under the compatibility layer.

Flag combinations

Each recording exercises the tabs and the tab state reflected in the URL, the code flow view, a comment (added or edited), and the status and severity modals including the comment field in each. The false-positive analysis drawer only exists on the enrichment page, so it appears in the two recordings with vulnerability_details_enrichment on. Across the set, both a status change and a severity change were submitted end to end on each Vue version, confirmed by the toast, the re-rendered sidebar, and the activity entry quoting the comment back.

vue3_migrate_vulnerability_details	vulnerability_details_enrichment	Recording
off	on
off	off
on	off
on	on

New-vulnerability form

Every field was filled with a value carrying a distinctive final token, then the form was submitted. The saved records were read back from the database and matched the typed values exactly, in every field, on both Vue versions.

The first recording is the baseline with the flag off. The second has the flag on and contains two submits in opposite field-fill orders. Two orders were used because the change handler re-emits every field of its own component, so only the field edited last in that component is at risk. Running both orders makes each field the last-edited one at least once.

Dependency-path drawer

This recording shows the drawer opening, the file dropdown inside it, and the drawer closing, using real server-side dependency-path data. The drawer body content is identical on both Vue versions; the only difference is the teleport target, which is the compatibility layer working as intended.

How to set up and validate locally

Checking out the branch and toggling the feature flags takes a few steps because of caching and memoization, so follow this order.

1. Toggle vue3_migrate_vulnerability_details from the GDK feature flag UI at http://gdk.test:3000/rails/features rather than the Rails console.
2. Run gdk restart vite and gdk restart rails-web. Both are needed because this MR adds vue3_migration.yml files: the entry map is built at vite startup, and Gitlab::Vue3Migration.definitions and the feature flag definitions are both memoized on the Rails side, so a stale process will not pick up the new files.
3. After toggling the flag, append a cache-busting query parameter to the page URL. The browser caches the page HTML, so without this the old entrypoint keeps being served and it looks like the flag did nothing.
4. Confirm Vue 3 actually loaded. Run document.querySelectorAll('[data-gitlab-vue3-app]') in the console; it should find the legacy details root and the new vulnerability root, since those are static imports and carry the marker. The enrichment root is loaded through a dynamic import and gets no marker, so there the proof is the console line Using Vue.js 3 for VulnerabilityDetailsEnrichmentRoot.

On the vulnerability details page, exercise the following with the flag on and then off. The page has a second, unrelated flag, vulnerability_details_enrichment, so cover all four combinations of the two flags.

1. The tabs, including the tab being reflected in the URL.
2. The code flow view.
3. Both side drawers.
4. Adding and editing a comment. Comments and history only exist on the legacy page, so this needs vulnerability_details_enrichment switched off. Not every vulnerability renders the comment box; vulnerability 817 in the root/vuln-showcase project does.
5. The status modal and the severity modal, including the comment field in each.

New vulnerability form

This is where the fixed regression lives. In Vue 3 compatibility mode, an @input listener sitting alongside v-model runs before the v-model assignment, so a handler that reads this.field emits the previous value and typed text is silently dropped on submit, with no warning; the record just saves wrong.

1. Fill every field (name, description, solution, identifier code, identifier URL), submit, then compare the saved record against a baseline created the same way with the flag off. Type into the field you care about last before submitting, since the symptom is losing the final character, or with the markdown editor a whole typing burst, from whichever field was edited last; a field edited early can look fine even when broken.
2. Run the same comparison for the identifier code and identifier URL fields, since those are covered by a separate fix in identifiers_table.vue.

Recorded evidence for the name, description and solution fields: four real submits in root/vuln-showcase, vulnerability 890 (Vue 3, before the fix, broken), 891 (Vue 2, before the fix), 892 (Vue 3, after the fix) and 893 (Vue 2, after the fix). The last three all saved correctly.

yarn jest ee/spec/frontend/vulnerabilities/new_vulnerability/ passes, 40 tests, both as is and with VUE_VERSION=3 set. Those specs pass with and without the fix, because Vue Test Utils calls listeners directly and never reproduces render-time ordering, so they cannot catch this class of bug; the browser comparison above is the real gate.

Two things you may see with the flag off that are known noise, not a regression from this MR: the console warning [BootstrapVue warn]: tooltip - The provided target is no valid HTML element, and a trailing slash appearing in URLs such as /784/?tab=code_flow.

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.

Related to #607918