fix(core): preserve HTTP error details

[burak33bb]

Primary change type

• Bug fix
• Documentation
• Feature
• Tests
• Dependency update
• Maintenance or refactor

Problem and motivation

Core HttpClient failures currently throw a plain Error, so callers lose the parsed response body, status text, and headers. That makes typed recovery from HTTP failures harder than it needs to be.

Summary and scope

Keep the existing error message, but attach structured HTTP details to the thrown error. The change is limited to the core client failure path and its existing test coverage.

Related work

Related issue or discussion: N/A — direct PR for a small core client bug. I checked recent related PRs; #598 and #625/#626/#627 cover different 402/header issues.

Validation

pnpm --filter @sapiom/core build — passed
pnpm --filter @sapiom/core typecheck — passed
pnpm --filter @sapiom/core lint — passed with existing warnings outside this change
pnpm --filter @sapiom/core test — passed

Tests and documentation

Kept the structured error test for a 402 response. Documentation is N/A because this does not add a package-root export or new public API.

Compatibility and release impact

• Breaking or externally visible changes: Non-breaking; existing error messages are preserved.
• Changeset: Added .changeset/preserve-http-error-details.md for @sapiom/core.

Security

• I have not included secrets, credentials, private data, or unsanitized logs.
• This pull request does not publicly disclose a suspected vulnerability. I
  will follow the
  Security Policy for
  private reporting.

AI assistance

• I did not use AI assistance for this change.
• I used AI assistance and have described it below.

Used Codex to inspect the client path, make the small code/test update, rebase the branch, and run validation.

Checklist

• I read CONTRIBUTING.md, and this contribution follows the direct-PR or issue-first policy.
• This pull request addresses one focused problem and contains no unrelated cleanup.
• I added or updated tests, or explained above why tests are not applicable.
• I ran the relevant build, typecheck, lint, and test commands, or explained
  any N/A checks above.
• I updated documentation for user-facing changes, or marked it N/A above.
• I added a Changeset for a published-package change, or explained why it is not applicable.
• I can explain and maintain every submitted change, including any AI-assisted work.