feat(backends): cap MemoryBackend with max_entries and LRU eviction

[allen0099]

Fixes #242

Stack 1/4 (roadmap #425): this → #334 (timedelta TTLs) → #335 (X-Cache) → #248 (@cached). Merge this one first.

Summary

• MemoryBackend(max_entries=...) caps the number of entries. Storing one past the limit evicts the least recently used entry, expired or not; a read hit and every write (set, set_if_absent, set_if_equals, expire_if_equals, increment) count as a use. Monitoring reads (get_all_keys, get_cache_data) and rejected conditional writes do not.
• self.cache becomes an OrderedDict (still a dict for callers); eviction is popitem(last=False), O(1).
• max_entries must be a positive int or None; the default stays unlimited, so nothing changes for existing users. Bytes are not counted.
• The "warn once on the implicit fallback" half of the issue already landed in Warn when the MemoryBackend fallback is registered implicitly (per-process cache under multiple workers) #327.
• Docs: BACKENDS.md (en + zh-TW) in-memory section; changelog.d/242.added.md.

Tests: tests/backends/test_memory.py (validation, LRU order, what counts as a use, replace-in-place, clear) and tests/test_cache_max_entries.py (a client varying ?junk= on a @cache(ttl=3600) route cannot grow the cache past the limit).

Checklist

• The issue above is assigned to me
• Tests under tests/ cover the change
• A changelog fragment changelog.d/<issue>.<section>.md (required for any change under fastapi_cachex/)
• uv run pre-commit run --all-files and uv run pytest pass

🤖 Generated with Claude Code

https://claude.ai/code/session_01UTXhK1BtwXTBDaouEcKtpW

---

Generated by Claude Code