Add fields=count mode to get-upcoming-counts (avoids hydrating + get_term_link per row when only a count is needed)

[chubes4]

Spun out of Extra-Chill/extrachill-events#168 (Redis cache-bloat audit).

Problem

UpcomingCountAbilities::executeGetUpcomingCounts() (inc/Abilities/UpcomingCountAbilities.php) always returns the full list of terms and calls get_term_link() for every row (UpcomingCountAbilities.php:226).

But at least one consumer — extrachill-events' extrachill_events_get_term_calendar_stats() — only uses count( $result['terms'] ), i.e. it throws away the term objects and links entirely. For a popular artist/location archive, this hydrates and warms term-link caches for every co-occurring venue/location for nothing.

On the events site (~51k artist terms, walkable via core sitemaps) this is per-pageview wasted work and contributes to object-cache warming under crawler load (see ec-events#168 for the broader bloat context).

Proposed fix

Add a fields input to the ability ('all' default, 'count' mode). In count mode:

• run the same GROUP BY SQL (it already produces one row per term),
• return just total => COUNT(*) (number of distinct terms with upcoming events) without the per-row get_term_link() loop or term hydration.

This lets extrachill_events_get_term_calendar_stats() ask for a scalar instead of a hydrated list.

Acceptance

• get-upcoming-counts accepts fields=count and returns { total: int } without per-row get_term_link().
• Existing fields=all (default) behavior unchanged.
• extrachill-events term-stats helper updated to use fields=count (separate PR in that repo).