Classify secondary and abuse rate limits separately from generic GitHub failures

[davidahmann]

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.