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.

account/getQuota の実装から始め、_bench/quota_cache_probe.py を実行して、プロセスの存続期間中のキャッシュ動作と取得タイムスタンプの動作を確認します。長時間稼働するプロセス内で繰り返し呼び出すと更新できるようになるか、キャッシュと reset_date のセマンティクスが SDK クライアント向けに明確に文書化されれば完了です。

索引モデルが issue の本文から書いたものです。