feat(quota): ✨ implement authoritative local counting and retry tracking

[Mirrowel]

Updates the usage tracking logic to handle providers where local counting is more accurate than API returns (specifically Antigravity).

• Implement sync_mode in UsageManager (force, if_exhausted, none) to control how API baselines affect local counters.
• Configure Antigravity credential manager to treat local counting as authoritative, skipping background refreshes to prevent valid usage data from being overwritten by stale API data.
• Add on_retry_attempt callback in RotatingClient and AntigravityProvider to track internal retries (bare 429s, empty responses) that consume quota.
• Introduce measured_max_requests tracking to dynamically learn the actual request limit of credentials.
  Linked to Bug: Quota count resets unexpectedly when background refresh syncs with API #75 and fix(usage_manager): 🐛 prevent stale API responses from resetting quota count (#75) #81

---

Important

Implement authoritative local counting and retry tracking for Antigravity provider with sync_mode and dynamic request limit learning.

• Behavior:
  • Implement sync_mode in UsageManager to control API baseline effects on local counters (force, if_exhausted, none).
  • Antigravity treats local counting as authoritative, skipping background refreshes to avoid overwriting valid data with stale API data.
  • Add on_retry_attempt callback in RotatingClient and AntigravityProvider to track retries (bare 429s, empty responses) that consume quota.
  • Introduce measured_max_requests tracking to dynamically learn actual request limits.
• Functions:
  • increment_request_count() in UsageManager to track retry attempts.
  • update_quota_baseline() in UsageManager updated to handle sync_mode and measured max requests.
• Misc:
  • Adjustments in client.py and antigravity_provider.py to integrate retry tracking and sync mode logic.

^{This description was created by for 2015eed. You can customize this summary. It will automatically update as commits are pushed.}

[Mirrowel]

@b3nw This is my take. Though, this feels way too bloated to commit without a major rethink. What do you think?

Difference here is that antigravity now only counts locally, except for first fetch and force fetch from the API. But, the retries in the provider make incrementing counts.. difficult.

[b3nw]

@Mirrowel -- I think I'd probably merge #81 and observe to see if the invisible retries actually cause quota drift, right now its hard for me to tell, but at least with the first fix, we'd isolate the issue, and if confirmed, implement the more complex tracking.

[Mirrowel]

@Mirrowel -- I think I'd probably merge #81 and observe to see if the invisible retries actually cause quota drift, right now its hard for me to tell, but at least with the first fix, we'd isolate the issue, and if confirmed, implement the more complex tracking.

Oh i know it is the case. No need to confirm for me - this is because of reporting in 20% increments. So api fetches are essentially useless for measuring quota accurately.

It is also rounded a bit, as you can get quota exhausted before you get the error. Suggesting the api refresh happened and you got hit with 0 remaining.

[Mirrowel]

Okay, this seems like a very bad idea. Entire usage manager needs to be refactored, as it was built on way too many times. It needs to be easily overridable by the providers.

Current logic in the PR is extremely shoddy when combined and anything short of rework is making it worse.