fix: do not present concert-stats failures as an empty history

[chubes4]

Problem

The Community profile card treats an unavailable or failed concert-stats response as a valid zero-show response for the profile owner.

Current behavior

ec_community_get_concert_stats() returns null when:

• the cross-site request primitive is unavailable;
• the Events REST request returns WP_Error;
• the response is malformed.

ec_community_display_concert_history() then converts any non-array result into total_shows = 0. For owners it renders:

You haven't tracked any shows yet.

Visitors see no card for the same failure, so owner and viewer behavior diverge.

Impact

• Temporary API, route-affinity, or plugin failures are misrepresented as user data loss.
• Owners are given a false empty-state CTA even when they have a populated history.
• Monitoring and support lose the visible distinction between no data and failed data.

Evidence

• inc/user-profiles/concert-history.php:42-74 — failures return null.
• inc/user-profiles/concert-history.php:153-178 — null is converted to zero and rendered as empty history.

Expected behavior

A successful zero-show payload and an unavailable stats payload remain distinct states. Failures should either suppress the card consistently or render a non-destructive unavailable state; they must not claim the user has no history.

Acceptance criteria

• Render the empty-history CTA only after a successful stats response with total_shows === 0.
• Handle missing primitive, WP_Error, and malformed payload as unavailable states.
• Owner and visitor handling follows one explicit failure policy.
• Preserve the brief negative cache without converting its sentinel into a valid zero result.
• Tests cover successful populated, successful zero, transport error, missing primitive, malformed response, cached failure, owner, and visitor.

Cross-repo dependency

No API response-shape change is required. The card must correctly interpret the existing distinction returned by its own fetch helper.