Classify secondary and abuse rate limits separately from generic GitHub failures

Problem
GitHub quota and abuse responses currently lose their specific classification in the shared error layer, so downstream tooling cannot distinguish them from generic 403/transport failures.

Why now
Rate limits are a routine operational condition for GitHub integrations. This server already documents structured error handling, but the central classifier only recognizes invalid token and insufficient scope today.

Evidence packet
- Commit under test: `0c0ac794a443626d3a1517f8154f109f06a26e68`
- Runtime: macOS 15.3 / Darwin 25.3.0 arm64, Go `1.25.7`
- Relevant codepaths:
- `pkg/errors/error.go`
- `pkg/utils/api.go`
- `docs/error-handling.md`
- Minimal repro:
1. Trigger a secondary rate limit or abuse-detection response from GitHub.
2. Observe the error payload stored in middleware / tool results.
- Expected: explicit classifications for secondary rate limits and abuse limits, ideally preserving retry timing when GitHub provides it.
- Actual: `classifyHTTPErrorCode` only handles `401 invalid_token` and some `403 insufficient_scope` cases, leaving rate-limit-specific failures unclassified.

Scope
This is a platform contract issue in shared GitHub error mapping.

Validation target
Unit tests should prove that primary, secondary, and abuse limit responses classify distinctly and preserve retry metadata when available.