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/18-provider-detection.txt

@@ -0,0 +1,15 @@
+# Nothing in application.yml selects a provider. Something still chose one.
+
+spring.cache.type          : (not set)
+resolved CacheManager bean : org.springframework.cache.caffeine.CaffeineCacheManager
+
+Caffeine is on this module's classpath because a later chapter needs TTL and
+size bounds. That single dependency moved every cache in the application off
+the ConcurrentHashMap-backed 'simple' provider, because Boot walks a fixed
+detection order and stops at the first provider it finds:
+
+  1 Generic      2 JCache      3 Hazelcast   4 Infinispan   5 Couchbase
+  6 Redis        7 Caffeine    8 Cache2k     9 Simple
+
+Nothing logs the decision at INFO. If a cache suddenly starts expiring
+entries, or stops, look at what changed in the dependency tree.