fix: reject cached browser HTTP error responses

[mirkobrombin]

Cached browser fetches currently treat 4xx/5xx responses as successful data, unlike the native helpers. Reject those statuses with the response text, leave JSON targets untouched, and preserve pending/cache/observer behavior. ClearCache remains the explicit retry mechanism.

Closes #86. Six new Chrome/WASM tests use controlled Fetch responses and real browser Response/Promise objects. They cover JSON, HTML and empty error bodies, cached errors, refetch, success and network rejection; four reproduced failures before the fix. HTTP package native race tests and native/WASM vet pass. The complete repository native race suite and native/WASM builds also pass. Full repository browser coverage remains a CI gate.

CI native, WASM/browser, iOS SSC, both lints and secret scanning passed. EUProvGuard still blocks release on the existing x/net 0.58.0 and x/crypto 0.55.0 findings also reported on #85; dependency remediation is separate.

Security baseline #88 now passes the full required CI, including EUProvGuard. A local combination of #88 and this HTTP fix passed Chrome HTTP, native HTTP/host tests and govulncheck. The release still requires reviewed integration and the #84 gate.

[pietrodicaprio]

Post-merge verification complete.

The implementation correctly aligns the browser FetchJSON / FetchText helpers with the native status >= 400 contract: failed responses settle the cache with an error, do not decode into the JSON target, preserve observer status, remain cached, and can be retried explicitly through ClearCache.

The browser coverage is proportionate and exercises JSON, non-JSON and empty error bodies, target preservation, cached failures, refetch, successful caching and network rejection. I found no blocking code findings in the change.

All required checks passed on the integrated revision, including native tests and reachable-vulnerability analysis, the full Chrome/WASM suite, iOS SSC, native/WASM lint, secret scan and EUProvGuard.

One documentation-only note: the PR description still contains the earlier statement that EUProvGuard and #84 block integration. Both prerequisites have now landed and the final integrated checks are green, so that status text is stale; it does not affect the merged code.