Classify secondary and abuse rate limits separately from generic GitHub failures

從 pkg/errors/error.go 中的 classifier 開始，接著追蹤透過 pkg/utils/api.go 處理 GitHub 回應的流程，並檢視 docs/error-handling.md。加入 unit coverage，顯示 primary、secondary 和 abuse limit 回應會被分別分類，並在可用時保留 retry 中繼資料；測試應針對參照的 commit 通過。

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.