feat(frontend): add reusable ApiError component with improved API error handling

[S-Garvit]

Summary

Adds a reusable ApiError component and improves API error handling across the frontend.

Changes

• Created a reusable ApiError UI component
• Replaced toast-based error handling with inline error display
• Improved error extraction from API responses (e.response?.data?.detail || e.message)
• Added dismiss functionality for error messages
• Ensured error state is reset before new requests

Affected Files

• frontend/src/components/ui/ApiError.tsx
• frontend/src/pages/NewAnalysis.tsx
• frontend/src/pages/Upload.tsx

Why this change?

• Provides a consistent and user-friendly way to display API errors
• Makes error handling more predictable and maintainable
• Improves UX by showing errors directly in context instead of transient toasts

Testing

• Triggered API errors manually (invalid inputs / failed requests)
• Verified error messages display correctly
• Verified dismiss button clears the error

[Oshgig]

Thanks @S-Garvit — this is a clean implementation and the component itself is well-built (aria-live, dismiss button, Tailwind classes consistent with the rest of the UI). I appreciate the care.

Before we land it though, I want to flag that PR #56 (@liascope) is doing essentially the same thing for the same issue, and it landed in the queue first. That PR is already in CHANGES_REQUESTED waiting on two small fixes, and we're going to merge that one once it's updated.

A few options that respect the work you've put in:

1. Help us land #56 faster. If you'd like, you can leave a code-review comment over there pointing at any improvements you think your version handles better (your e?.response?.data?.detail parsing is genuinely nicer than just String(e) — that would be a great suggestion to lift over).
2. Follow-up PR after #56 merges. Once #56 is in, the ApiError component will exist; you can then open a smaller PR that adds the structured e?.response?.data?.detail || e?.response?.data?.message || e?.message parsing pattern across both pages. That's a clear, focused improvement.
3. Close this one in favour of #56. Totally reasonable too — your contributions show up on your profile either way.

Whatever you prefer is fine. If I don't hear back I'll close this one in ~5 days in favour of #56 to avoid the queue staying confusing for other contributors. Sorry for the duplicate-work outcome — we'll get better at issue triage to prevent this in future.

Also, two small things on the diff itself for whatever path you take:

• ApiError.tsx is missing a trailing newline (No newline at end of file).
• In Upload.tsx the catch block no longer calls showToast('error', ...), only setError(...). The toast on NewAnalysis.tsx is still there. Worth keeping the behaviour symmetric — pick one or the other for both pages.

Thanks again for engaging with the project.

[Goldokpa]

📢 Heads-up: repo history was rewritten today (2026-05-18)

We force-pushed a cleaned history across all branches to remove an internal directory from past commits. Your code and this PR are unaffected — only the commit SHAs underneath have shifted. GitHub will re-render the diff against the new base automatically.

If you have a local clone, please bring it back in sync before pushing anything else:

# Option A (simplest): fresh start
git clone https://github.com/Climate-Vision/ClimateVision.git

# Option B: rebase the existing PR branch in your fork
git fetch origin
git checkout <your-branch>
git rebase origin/main          # likely no conflicts
git push --force-with-lease

Do not git pull on an existing clone — it will produce a messy non-fast-forward state. Either re-clone, or rebase explicitly as above.

Apologies for the interruption — really appreciate your patience here. If anything looks off after rebasing, leave a comment and I'll help unblock right away. Thanks for contributing 🙏