Feature/Proactive Rate Limitting in Github Client

[riturajFi]

This PR implements proactive rate-limit handling for the GitHub API in DefaultGithubClient.

Previously, the application only reacted after hitting a 403 RateLimitExceeded error. With these changes, the client now:

✅ Reads X-RateLimit-Remaining and X-RateLimit-Reset headers from each GitHub API response.
✅ Tracks the remaining quota and reset time internally.
✅ Checks the quota before each request and pauses (with sleep) when the quota is near exhausted, avoiding unnecessary failures.

This improves stability and avoids API bans, especially under heavy load or with many tracked repositories.

Changes
Add RateLimitState struct inside DefaultGithubClient (with Arc<Mutex<...>>).
Update state after every response using the provided rate-limit headers.
Add rate_limit_guard() method that blocks requests if remaining quota is below a safety threshold.
Call rate_limit_guard() at the start of every execute_graphql() call.
Linked Issue
Closes #67

[isSerge]

This is a significant improvement, few minor comments below.

Also, check cargo clippy - there are some warnings, and run cargo fmt. I will update CI to run these for all branches, not just main

Thanks!

[isSerge]

Suggested change

	GithubError::HeaderError(_) => {
	tracing::error!("Header error while polling issues for repository");
	}
	GithubError::HeaderError(msg) => {
	tracing::warn!(
	"Could not parse rate limit headers for repo {} (chat {}): {}. \
	Skipping this repo for this cycle.",
	repo.name_with_owner,
	chat_id,
	msg
	);
	}

[riturajFi]

@isSerge requesting review. resolved the cargo fmt issue

[isSerge]

Thanks for your hard work @riturajFi

[riturajFi]

Thanks for your guidance! More to come!!