account/getQuota is served from a process-lifetime cache; reset_date is the fetch timestamp

**SDK:** github-copilot-sdk 1.0.8 (Python) · **CLI/runtime:** GitHub Copilot CLI 1.0.83 · Windows 11

## Summary
`client.rpc.account.get_quota()` returns the same answer for the lifetime of the runtime
process. A long-lived client that polls it to show live usage never sees the figure move.
Separately, `reset_date` on each snapshot is the runtime's fetch timestamp, not a reset
instant.

## What I observed (2026-09-11)
- A client started 2026-09-08 09:32 read `premium_interactions.used_requests = 190`
(of 5000) at startup. It re-called `get_quota` every 120 s for three days and got 190
every time. Meanwhile the account went to 5000/5000 (copilot-cli statusline:
`Plan: 100% used`; the runtime's own `session-store.db` ledger: 4,922 credits this
month on this machine). A fresh process, started at that point, read 5000/5000 on its
first call.
- Two calls 40 s apart in ONE fresh process returned byte-identical snapshots, including
`reset_date` (`2026-09-11T05:03:07.217Z` both times). A new process a minute later
stamped `05:04:32Z`. So `reset_date` records when the runtime fetched, and identical
stamps mean "served from cache".
- Passing `git_hub_token` in `AccountGetQuotaRequest` does bypass the cache (fresh stamp
5 s later), but that needs the Copilot OAuth token itself, which the SDK does not expose.

## Why it matters

Agents that run for days (batch relays, always-on assistants) are exactly the ones that
need to watch the allowance. Mine drained a month's credits overnight while its status
line still said 4,810 left.

## Ask

Either of:
1. A TTL or a `force_refresh` flag on `account/getQuota`, or
2. Document the caching and the actual semantics of `reset_date`, so clients know to
combine the snapshot with the local usage ledger (which is what I ended up doing).

## Repro

`_bench/quota_cache_probe.py` in https://github.com/aweussom/agentry calls `get_quota`
twice in one process 40 s apart, then once from a fresh process. Same-process stamps
are byte-identical; the fresh process carries its own. Re-verified today at 0/30/60/120 s:
fresh processes always fetch, so the cache is per process, not server-side.

Start with the account/getQuota implementation and run _bench/quota_cache_probe.py to confirm the process-lifetime cache and fetch-timestamp behavior. Done means either repeated calls can refresh within a long-lived process, or the caching and reset_date semantics are documented clearly for SDK clients.

Written by the indexing model from the issue text.