fix(#10): use friendly fallback when API omits error

[dyk1454683243-sudo]

Summary

Fixes #10 — replace the client fallback 'Request failed' with a short sentence that matches the server voice in utils/friendlyError.js.

Changes

• src/shared/api.js: when the API omits an error field, show Something went wrong. Please try again. (same wording as the server default)

Out of scope

• Offline / unreachable-host paragraph left as-is (intentionally more detailed)
• No API status or response-body changes

Test plan

• Trigger an API error without an error field (or temporarily force the fallback) and confirm the status toast reads the new sentence
• Confirm server-provided error strings still surface unchanged

[vercel]

@dyk1454683243-sudo is attempting to deploy a commit to the solabode499-5056's projects Team on Vercel.

A member of the Team first needs to authorize it.

[DevOlabode]

Nice fix for the missing-error-field case, but there's a gap: when the response body isn't valid JSON (e.g. a 502/503 HTML page from a cold-starting Render backend), parseJson's catch branch returns { error: text } — the raw response text — which is truthy, so it bypasses the friendly fallback entirely. That raw HTML then gets thrown as the ApiError message and rendered verbatim in the popup.

Given this extension already anticipates Render cold-starts elsewhere ("server may still be waking up"), a non-JSON gateway error during wake-up seems like the more likely trigger for issue #10 than a plain missing error field. Can we treat an unparseable/non-JSON error body the same as a missing one, so it also falls through to the friendly message? (src/shared/api.js:52, and the parseJson catch around line 19.)

[dyk1454683243-sudo]

Withdrawing this PR while I clean up a high-volume open-PR backlog. Sorry for the noise — happy to come back later with a focused change if useful.