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/13-transactions.txt

@@ -0,0 +1,22 @@
+# A rollback does not roll the cache back
+
+cacheManager : org.springframework.cache.concurrent.ConcurrentMapCacheManager
+
+nameOf(1) -> Alice
+
+An outer @Transactional method calls the @CachePut update, which succeeds,
+and then fails on the next step. The transaction rolls back.
+
+what the cache serves : Alice Cooper
+what the database has : Alice
+
+The cache is now holding a name that no transaction ever committed. Nothing
+will correct it until the entry expires or something evicts it.
+
+--- the same shape with @CacheEvict ---
+nameOf(2) -> Bob
+after the rollback, nameOf(2) -> Bob
+database loads: 2   <- the entry was evicted, so this one reloaded
+
+An eviction that fires too early is self-healing: the next read goes to the
+database and re-populates correctly. A @CachePut that fires too early is not.