Plugin badge reuses dashboard cache instead of new state

A client wanted a small badge on each site's 🔌 button showing how many plugin updates were still pending. The interesting decision wasn't the UI, but the data source: instead of building a new API endpoint and cache, the team reused the existing _updatesDashState cache that already powered the cross-site updates dashboard. Looking up a site by id and reading plugins.length was enough to produce the badge count.

This reuse paid off quietly: when the cache is invalidated during maintenance, the badge disappears automatically with no extra sync code, the existing TTL logic carries over, and there's no second copy of the count that can drift out of sync. Noise was cut with clear thresholds — no badge for zero pending updates or unchecked sites, and counts above 99 are capped as '99+' for consistent layout.

Both update paths — the cross-site dashboard and per-site checks — write back to the same cache, so either workflow keeps the badge accurate. Must-use and dropin plugins are excluded from the count to avoid a badge that promises an update the UI can't actually perform.

The underlying lesson: a new UI element doesn't automatically need a new data source. Checking whether existing state already answers the question can save teams from unnecessary sync logic and state duplication.