[CHORE] Decide whether to render or remove per-package registry data

[lukekarrys]

Context

The pipeline generates registryPerPackageCountChartData for every date. The app also computes and plumbs registryAveragePerPackageData, but the registries page does not currently render a per-package widget. This unused path contributed to the registry history unit mismatch because per-package data was consumed where total seconds were expected.

Decision needed

Choose one direction:

1. Render per-package registry performance as a first-class, correctly labeled ms/package view or toggle, similar to the package-manager pages; or
2. Stop generating and plumbing the unused registry per-package fields.

The decision should be consistent with the separate history-chart source/unit fix.

Acceptance criteria

• The intended user-facing role of per-package registry data is documented.
• If retained, it is rendered with correct units and clear semantics.
• If removed, generation, types, normalization, averages, and unused UI plumbing are removed together.
• Current and historical chart-data.json compatibility is considered.
• Tests cover the selected direction.

Source

Performance investigation: item 3 — vestigial per-package registry data