backstage-cataloglisted

# Backstage Software Catalog Model entities correctly, ingest them from external systems without destroying data, and diagnose what the catalog actually believes. ## Preconditions - Release line from `backstage.json`; catalog packages resolved via `yarn why @backstage/plugin-catalog-backend`. - Backend generation: `packages/backend/src/index.ts` using `createBackend()` + `backend.add(import('@backstage/plugin-catalog-backend'))` is the new backend system. A `CatalogBuilder` in `packages/backend/src/plugins/catalog.ts` is the legacy backend — migrate it (`backstage-plugin-migrate`) before adding modules, or register through the builder and say so in your report. - Exact interface shapes (`EntityProvider`, `EntityProviderConnection`, `CatalogProcessor`, `DeferredEntity`, `processingResult`) read from the **installed** `@backstage/plugin-catalog-node` types, not from memory. - A running local backend or a reachable catalog base URL, plus a token if auth is enforced, before any debugging step. ## Procedure 1. **Read the catalog's current belief before changing anything.** Query the API rather than guessing: - `GET /api/catalog/entities/by-query?filter=kind=component&fields=metadata.name,metadata.annotations` — what exists and where it came from. `POST` to the same path for `$all`/`$any`/`$not`/`$exists`/`$in` predicates. - `GET /api/catalog/entities/by-query?filter=metadata.annotations.backstage.io/orphan=true` — the orphan set. - `GET /api/catalog/entity-facets?fac