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/07-mutable-key.txt

@@ -0,0 +1,18 @@
+# A mutable argument is an entry you cannot find again
+
+first call  : byList([java]) -> tags=[java]
+  cache "mutable":
+    key [java]                 [ArrayList]   ->  tags=[java]
+
+the caller mutates the same list it passed in: [java, spring]
+second call : byList([java, spring]) -> tags=[java, spring]
+
+  cache "mutable":
+    key [java, spring]         [ArrayList]   ->  tags=[java]
+    key [java, spring]         [ArrayList]   ->  tags=[java, spring]
+
+Two entries, and their keys now print identically - because they are the
+same object. The caller mutated the list it had already handed over as a
+key, so the first entry sits in the map under a hashCode the map no longer
+agrees with. Nothing will find it again and nothing will evict it: a leak
+with a completely ordinary-looking cause.