Hey,
First, thanks for all the great work on this client!

I noticed a couple of issues with the rate limits (please let me know if you think I should split it into two issues):

1. PR Add fields to RateLimits struct #2340 added support for all rate limit categories.
   as @gmlewis pointed out in this discussion, all categories should be handled in the catgory() function.
   The current code is:

func category(path string) rateLimitCategory {
	switch {
	default:
		return coreCategory
	case strings.HasPrefix(path, "/search/"):
		return searchCategory
	}
}

which is used in:
rateLimitCategory := category(req.URL.Path)
this variable is used in 2 points:
c.checkRateLimitBeforeDo(req, rateLimitCategory)
and
c.rateLimits[rateLimitCategory] = response.Rate

Now, since all categories (but search) are aggregated into the Core category on every request,
the result is that checkRateLimitBeforeDo might prevent the user from issuing a request, although the rate limit wasn't reached.
I can try to add partial support for that, at least for the fields that are in the documentation or are easy to deduce (e.g. code_scan_upload / integration_manifest)

2. The secondary rate limit is handled in CheckResponse(), but not in checkRateLimitBeforeDo().
   As a result, there is no built-in protection against the secondary rate limit, which would be valuable.
   I can try to add support for that as well, but I'm not sure to which request the secondary rate limit applies:

• The very same request
• All requests in the same category.
• Any request from that user.

I hope someone here might know the answer.

On the same note, I'd be glad to hear your thoughts on implementing an optional 'wait for secondary rate limit' configuration in the client. IMO the use case of waiting for the secondary rate limit is much more common than waiting for the hour-long rate limit (which also isn't supported).