Problem

Multiple client-side data fetchers swallow errors with catch {} or catch { /* non-critical */ }, leaving the UI in ambiguous states (spinner stops, but nothing renders; or no error message is ever shown).

Known locations (non-exhaustive):

• src/pages/challenges/index.tsx:86-97 — fetchRecommended() and fetchHistory() have empty catches. On failure, loading stops but no error is surfaced.
• src/pages/challenges/index.tsx:189-206 (approx) — submit and hint handlers swallow errors.

Expected behavior

Every network failure either:

1. Triggers a user-visible toast/alert with a retry button, or
2. Sets an error state that the component renders (with a retry affordance).

And in all cases, the error is logged to the console and Sentry / equivalent monitoring.

Acceptance criteria

• Grep the codebase for catch {}, catch {\n}, catch.*{\s*\/\/ — fix every instance in client-side handlers.
• Establish a single pattern (e.g., a useFetchWithToast hook or handleClientError(err, { toast: true }) helper) to avoid per-site inconsistency.
• Add a lint rule (Biome or ESLint) to flag empty catch clauses.
• Verify the pattern works for both async/await and .then/.catch.

Suggested approach

Centralize:

export function handleClientError(err: unknown, opts: { context: string; toast?: boolean }) {
  console.error(`[${opts.context}]`, err);
  // TODO: Sentry.captureException(err)
  if (opts.toast) toast.error("Something went wrong. Please try again.");
}

And replace each catch {} with catch (err) { handleClientError(err, { context: "fetchRecommended", toast: true }); }.