backstage-plugin-migratelisted

# Migrate a Backstage plugin to the new frontend/backend systems Convert a legacy plugin package to the New Frontend System (NFS) and/or New Backend System without changing what users see, using dual exports so one package serves both systems during the transition. Scope, map, verify parity. ## Preconditions - Generation known for **both** plugin and host app. Run `backstage-repo-discovery`, or grep: `createPlugin`/`createRoutableExtension`/`<FlatRoutes>`/`createApp` from `@backstage/app-defaults` = legacy frontend; `createFrontendPlugin`/`createApp` from `@backstage/frontend-defaults`/`/alpha` imports = NFS. `createBackend` + `backend.add()` = new backend; `createRouter` + `plugins/*.ts` env wiring in `packages/backend/src` = legacy backend. - `backstage.json` release line recorded, workspace build and tests green on `main` before you touch anything. Migration on a red baseline is unverifiable. - The plugin's consumers are known. If it is published outside this repo, legacy exports must survive; if internal-only, they may be deleted at the end. - Node 22 or 24, `yarn` at the repo root. ## Procedure 1. **Scope the migration.** Inventory the plugin's surface: pages, entity page tabs, entity cards, utility APIs, route refs (internal and external), nav items, search result items, context-menu items, backend routers and modules. Each maps to exactly one blueprint below. Do NOT migrate frontend and backend in one commit, and never fold a Material UI