Enhance error mapping and typed error hierarchy in @astroid/errors

[Cjay-Cyber-2]

Description — what to implement and the why/impact.

Developers integrating Astroid SDK packages need precise error handling to distinguish between validation failures, authorization errors, rate limits, and upstream API crashes. This issue expands the shared error types and response parsing in the error package.

Context & Requirements — background, constraints, design references, edge cases; grounded in the actual repo (real files, stack, conventions).

Build out or refine error classes (e.g., ValidationError, AuthenticationError, RateLimitError, ApiError) that inherit from a common base AstroidError. Each error class must parse error response bodies containing code, message, and details fields conforming to Astroid API error standards.

Acceptance Criteria — a checklist ("- [ ] ...") of specific, testable conditions that define "done".

• Define distinct error classes covering 400, 401, 403, 404, 429, and 5xx status codes.
• Implement response body parsing to extract error codes and validation details.
• Export all error classes from the package entry point with complete TSDoc comments.
• Add unit tests covering error serialization and status-code-to-class mapping.

Implementation Guidance — likely files/modules to touch (use real paths from the repo context) and a suggested approach, without over-prescribing.

Look for error definitions across workspace packages (such as packages under packages/). Ensure strict TypeScript typing with no any casts.

Testing & Validation — how the contributor should prove it works (tests to add/run, manual checks, screenshots for UI).

Run pnpm test and pnpm typecheck across the workspace to verify compilation and test suites.

Submission Guidelines — must open a PR that includes "Closes #"; assignment is required before starting; follow the repo's existing style and conventions.

---

Wave complexity: Medium