Show telemetry failures instead of empty console states

[albertovincenzi]

Problem

Several console reads explicitly catch every API error and replace it with null or an empty array. This makes an unavailable or corrupt telemetry source visually identical to a healthy source with no events.

In particular, a backend 502 for history, live shared-budget state, or recent breaches would still render as "nothing to show", defeating the fail-closed API fixes and potentially allowing the Overview to claim every target is under its caps without a readable breach log.

Fix

• Let rollup request failures reach Budget History's existing error panel; only a successful empty response remains "nothing to read".
• Let trace read failures reach the Traces error panel while keeping the target index optional because it only populates a filter.
• Let shared-budget failures reach the page error panel; a successful empty array remains "no shared budget declared".
• Require the breach read for the Overview health claim; a successful empty list is still the normal no-breach state.
• Keep optional application-list enrichment on Targets unchanged.

Before / after

Before: 401/403/500/502/network errors on these core reads could become empty charts, empty event lists, or benign setup guidance.

After: the existing page-level error UI shows the API's concrete message. Empty states now mean the server successfully returned no data.

Verification

• npm run build
• npm audit --audit-level=high (0 vulnerabilities)
• git diff --check

Review notes for Alice

This is deliberately a frontend-only PR on master. It does not depend on the backend PRs, but it is what makes their explicit 502 responses visible to an operator. The two remaining catches are intentional enrichment fallbacks: the target list on Traces only fills a dropdown, and the application index on Targets only adds group totals.