PR 説明文

Here's the PR body:

## Summary

Checkout called the FX provider on every cart render. During Friday's sale that went over the provider's 1,000 requests/minute limit, and checkout started returning 429 errors. `get_rate` now keeps each rate in memory for 5 minutes.

```diff
 get_rate(base, quote)
+  if base:quote was fetched less than 300s ago
+    return the saved rate
   GET api.example-fx.com/latest
   raise on HTTP error
+  save rate for base:quote with time.monotonic()
   return rate

Evidence

• Before: pytest shows 14 passed. Every get_rate call makes its own HTTP request.
  After: pytest shows 15 passed. Added test_get_rate_uses_cache_within_ttl:

  get_rate("USD", "EUR")
  get_rate("USD", "EUR")
  assert provider was called once
  

Merge Danger

Door: two-way

The cache only lives in memory, with nothing persisted and no schema change. To roll back, revert the commit.

Blast Radius: checkout

• Stale rates: prices can use a rate up to 5 minutes old. Confirm that's acceptable for checkout pricing.
• Per-process cache: each worker keeps its own cache. Provider calls per 5 minutes are roughly workers × currency pairs, so the limit could still be reached with many workers.
• No size limit or eviction: this is fine for a fixed set of currency pairs.
• No locking: two requests that miss the cache at the same moment can both call the provider. The only cost is an extra request.
• Test isolation: _cache is module-level, so it carries over between tests unless a fixture clears it.

- **No `GLOSSARY.md`:** the repo doesn't have one, so I used the wording from your context and the code.
- **Check this before merging:** `test_get_rate_returns_quote` already caches `USD:EUR`. If nothing clears `_cache` between tests, the new test should see 0 provider calls and fail. Since it passes, the `mock_get` fixture probably resets the cache, but I couldn't see the fixture to confirm. If it doesn't, the test result depends on the order tests run in, and I'd add an autouse fixture that calls `_cache.clear()`.