Get Org Catalog Stats

Filter-chip counts for the org-wide catalog, computed server-side.

The skeleton payload has no columns, so the client can no longer count them. Aggregate in SQL so large governed catalogs do not need to load and serialize every asset merely to compute six counters.

The counts are faceted: every chip counts under the OTHER active filters, never under its own. A chip that counted itself would report its own total and leave every sibling at zero; one that ignored the rest promised rows the list could not deliver ("Published 22" landing on 4 with a tag on).

Status, pending-suggestion and open-question are already the GROUP BY of _aggregate_db_stat_rows, so their per-chip exclusion is arithmetic over the returned groups. Tag and asset type narrow the SQL: the semantic layer's kind chips (Metrics / Models / Terms) sit in the same band as the counted chips, so a count that ignored them would disagree with the list next to it.

Text search deliberately does NOT reach here: matching it exactly would mean replaying search_catalog_page's COLUMN-to-parent fold in the aggregate, and two copies of that predicate would drift. The client hides the badges while a text query is active instead.