fix(frontend): decode blob error bodies so tools show the server's reason

[posthog-eu]

Description of Changes

Why

• Users who hit a server error in any PDF tool saw the generic toast "Server error: There was an error processing your request." instead of the server's reason. On merge, they retried, rage clicked, and gave up.
• This is live on the hosted product, not only self-hosted. Rage clicks on /merge are the one measurable proxy, and none of these failures reach error tracking.

What changed

• handleHttpError built the toast from error.response.data before the Blob was decoded. Every tool POST sets responseType: "blob", so at that point the body was an unread Blob: JSON.stringify(Blob) returns "{}", the message was rejected as unhelpful, and it fell back to the generic text — the decoded server explanation was then never used for the toast.
• Decode the response body once, up front, and pass the decoded body into extractAxiosErrorMessage.
• extractAxiosErrorMessage now takes an optional decoded-body argument and prefers it over the raw error.response.data.

Impact

• Repairs error legibility for every tool that posts with responseType: "blob", not merge alone.
• The underlying merge 500 is now diagnosable, because the server message reaches the toast.

Tests

• Added httpErrorHandler.test.ts: a blob error body (JSON and plain text) now surfaces the server message in the toast instead of the generic fallback.

---

Checklist

General

• I have read the Contribution Guidelines
• I have read the Stirling-PDF Developer Guide (if applicable)
• I have read the How to add new languages to Stirling-PDF (if applicable)
• I have performed a self-review of my own code
• My changes generate no new warnings

Documentation

• I have updated relevant docs on Stirling-PDF's doc repo (if functionality has heavily changed)
• I have read the section Add New Translation Tags (for new translation tags only)

Translations (if applicable)

• I ran scripts/counter_translation.py

UI Changes (if applicable)

• Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)

Testing (if applicable)

• I have run task check to verify linters, typechecks, and tests pass
• I have tested my changes locally. Refer to the Testing Guide for more details.

---

Created with PostHog Desktop from this inbox report.