Add caching: the Spring cache abstraction, keys, eviction timing and the self-invocation trap

A Spring Boot 4.1.1 module whose test suite is the evidence for the article: 19 tests
producing 22 transcripts under docs/output/, plus 12 documentation chapters.

Findings the build pins:
- @EnableCaching has no exposeProxy attribute; the widely-copied
  @EnableCaching(exposeProxy = true) does not compile.
- Two methods sharing a cache name and an argument type share a key space, and one
  silently serves the other's answers.
- beforeInvocation = true is NOT deferred by TransactionAwareCacheManagerProxy on
  7.0.9 - doEvict picks evictIfPresent, which the decorator does not intercept.
- Four of five invalid declarations start a clean context and throw at the first call.
- Caffeine on the classpath silently displaces the simple provider.

caching/docs/output/08-evict-timing.txt

@@ -0,0 +1,17 @@
+# @CacheEvict runs after the method - unless you ask otherwise
+
+price("sku-1") -> 100   (stored price is 100)
+
+updatePrice("sku-1", 250, fail=true) threw after writing the new price.
+stored price now  : 250
+price("sku-1")    : 100   <- the cache still serves the old value
+reads of the real store: 1
+
+--- beforeInvocation = true ---
+price("sku-2") -> 100
+updatePriceEvictFirst("sku-2", 250, fail=true) threw the same way.
+price("sku-2")    : 250   <- the entry went first, so the next read is honest
+
+--- @CachePut instead: write through, no miss ---
+after @CachePut, price("sku-3") -> 400
+reads of the real store: 1 -> 1   <- no reload was needed