flaky test: oauth::second_call_within_expiry_hits_the_cache fails intermittently on CI (cache miss on 2nd sequential call)

Observed on PR #811 CI (run 29995107963, job 89166828069, commit 333ce37 — a change confined to crates/aisix-proxy/src/videos.rs; the aisix-mcp crate is untouched):

thread 'oauth::tests::second_call_within_expiry_hits_the_cache' panicked at crates/aisix-mcp/src/oauth.rs:365:
assertion `left == right` failed: second call must be served from cache

The test mints a token with expires_in: 3600 and asserts the second sequential get_or_fetch is served from cache (endpoint.hits() == 1). A miss between two sequential calls with an hour of validity should be impossible unless the token cache is process-global and subject to interference from sibling tests running in parallel in the same binary (eviction from a bounded cache, or key collision/cleanup between tests). Passes locally and on the same code in earlier runs — timing/parallelism dependent.

Worth checking:

• whether the oauth token cache is a shared/global structure across tests, and whether it is bounded (parallel sibling tests could evict this entry);
• whether the fix is test isolation (per-test cache instance) rather than loosening the assertion.

Not weakening the assertion in the PR that observed it — filing per test-discipline (failures get root-caused, not silenced).

Start with crates/aisix-mcp/src/oauth.rs and the oauth::tests::second_call_within_expiry_hits_the_cache test; run it under the affected CI conditions and inspect how the token cache is shared, bounded, and cleaned up across sibling tests. Done means the sequential second get_or_fetch consistently hits the cache with endpoint.hits() == 1, without weakening the assertion.