Add MFE admin UI for runtime version management

What does this MR do and why?

Part 5 of the registry-direct MFE series: the admin UI over part 4's JSON API.

  • Table of every baked app with three version columns — Baked, Override (— when none) and Served — where a not-served override gets a popover explaining why (GitLab downgraded below the activation version, baked version overtook the override, or override state unreadable) and forewarning that upgrades reclaim serving.
  • Change version opens a drawer that lists published versions fetched straight from the configured registry by the browser ({registry_url}/{app}/manifest.json, CORS) — the GitLab server never contacts the registry. The confirm step displays the exact version-manifest checksum that gets recorded and later enforced by the runtime loader (part 6a).
  • Reset returns serving to the baked version. Registry/network failures render an actionable retry state.

How to verify

yarn jest spec/frontend/admin/mfe

Everything is gated behind mfe.enabled + mfe_enabled (the page 404s otherwise).

Screenshots or screen recordings

Live demo of the full chain lands with part 6b; this page is exercised there.

Stack

# Scope MR
1 Config section + instance kill switch !246732 (merged)
2 Vendor pin file + registry manifest schema + verified bake task !246736 (closed)
3 Version overrides table + resolver !246753 (closed)
4 Admin API + routes + sidebar !246758 (closed)
5 Admin UI (Vue) this MR
6a Runtime loader: gon contract, manifest verification + SRI, baked fallback, CSP connect-src !246775 (closed)
6b Duo Chat consumer behind mfe_duo_chat !246778 (closed)
7 Developer mode (local dev server + HMR) !246833 (closed)

Related to #605798.

Edited by Illya Klymov

Merge request reports

Loading