Feature: WithResetOnSuccessfulCall Option

[3choBoomer]

Feature: WithResetOnSuccessfulCall Option

This PR introduces a new request option, WithResetOnSuccessfulCall, designed to handle discrepancies between the client-side rate limiter and the actual GitHub API state.

Problem:
This transport could be stacked with others, including an auth management transport like https://github.com/bored-engineer/github-rate-limit-http-transport. Continuing to wait on non-rate-limited responses would continue blocking when there could potentially be tokens available downstream.

Solution:
The WithResetOnSuccessfulCall option allows an application to send a "probe" request.

• Behavior: When this option is enabled on a request, and that request successfully completes (returns a successful HTTP status code), the github_primary_ratelimit will reset the tracking state for that specific resource category.
• Outcome: This effectively "unblocks" the category, allowing subsequent requests to flow normally.

Usage:
This is best used in conjunction with WithLimitBypass on a single request to periodically probe a blocked category to see if the rate limit on the server side has actually expired or if the client was mistakenly blocking.

---

• Fix parseRequestCategory logic:
  • Changed github_primary_ratelimit/category.go to use request.URL.Path instead of request.URL.RawPath.
  • Reason: RawPath is often empty in Go's net/url when the path contains no characters requiring special encoding. This caused standard endpoints (like /search) to fail string matching and incorrectly default to the core limit category. Path is the reliable field for routing logic.