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/14-cached-entity.txt

@@ -0,0 +1,16 @@
+# Caching an entity caches a detached object, lazy proxies and all
+
+loadEntity(1) -> Alice (com.ankurm.caching.jpa.Customer)
+database loads: 1
+second call returns the same instance? true
+database loads: 1
+
+--- touching the lazy collection outside the session ---
+org.hibernate.LazyInitializationException
+  Cannot lazily initialize collection of role 'com.ankurm.caching.jpa.Customer.orders' with key '1' (no session)
+
+This is the line between the two caches. Hibernate's second-level cache
+stores dehydrated entity state and rebuilds a managed entity inside a
+session, so lazy associations still work. The Spring cache abstraction
+stores the object your method returned, exactly as it was when the
+transaction ended - detached, with whatever its proxies were holding.