`SimpleIconsEntityPresentationApi` issues one `getEntityByRef` per ref — request storm on large catalogs

[dfl-aeb]

Affected package

@dweber019/backstage-plugin-simple-icons@0.1.2 (latest), Backstage 1.51.x

Problem

SimpleIconsEntityPresentationApi.forEntity resolves the icon by calling
catalogApi.getEntityByRef(entityOrRef) individually for every rendered
entity ref:

promise: this.catalogApi.getEntityByRef(entityOrRef).then(entity => {
  if (entity) {
    entityRefPresentation.snapshot.Icon = this.getIcon(entity, ...);
  }
  return entityRefPresentation.snapshot;
});

Since Backstage 1.51 the catalog UI resolves every owner/relation/owned-by
ref through the EntityPresentationApi. On a large catalog this produces one
unbatched HTTP request per displayed ref — hundreds to thousands of parallel
GET /catalog/entities/by-name/... calls. They exhaust the browser's per-host
connection pool, and otherwise-valid requests start failing with
TypeError: Failed to fetch. The whole catalog UI becomes unusable.

The wrapped DefaultEntityPresentationApi already batches its own lookups via
getEntitiesByRefs + a DataLoader; this plugin's extra per-ref fetch bypasses
that batching — and fetches the full entity for 100% of refs even though
only the few with a simpleicons.org/icon-slug annotation use the result.

Suggested fix

Coalesce the per-ref fetches into a batched getEntitiesByRefs call via a
DataLoader (the same primitive DefaultEntityPresentationApi uses), fetching
only metadata.annotations (+ kind/name/namespace). This collapses N requests
into ⌈N / batchSize⌉ and removes the storm. Caching per loader also dedupes
repeated refs.

I have a working wrapper that does exactly this (a DataLoader-backed
getEntityByRef façade over the CatalogApi) and would be happy to open a PR
if you're open to it.