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/08-providers-and-ttl.md

@@ -0,0 +1,77 @@
+[← sync and async](07-sync-and-async.md) · [next: versus Hibernate L2 →](09-versus-hibernate-l2.md)
+
+# 8. Providers, TTL, and the dependency that changes your cache
+
+## The abstraction has no TTL
+
+None. No time-to-live, no time-to-idle, no maximum size, no eviction policy. Those are provider
+features, and the reference documentation says so plainly.
+
+On the default `simple` provider — a `ConcurrentHashMap` behind `ConcurrentMapCache` — an entry
+stays until something evicts it by hand or the process ends. That is fine for a lookup table with
+twelve rows and a slow leak for anything else.
+
+With Caffeine configured for `expireAfterWrite=400ms, maximumSize=3`,
+`docs/output/15-providers-and-ttl.txt`:
+
+```
+two calls, same key, immediately -> 1 repository calls
+one more call 600 ms later      -> 2 repository calls   <- the entry expired
+
+five distinct keys written, maximumSize = 3
+estimated size after eviction settles : 3
+stats                                 : hits=1 misses=5 evictions=3
+```
+
+## Auto-detection, and why your provider changed
+
+If there is no `CacheManager` bean and no `cacheResolver`, Spring Boot walks a fixed order and
+stops at the first provider on the classpath:
+
+```
+1 Generic   2 JCache   3 Hazelcast   4 Infinispan   5 Couchbase
+6 Redis     7 Caffeine   8 Cache2k   9 Simple
+```
+
+That has a consequence worth internalising. This module added Caffeine because one chapter needed
+TTL. Every cache in the application moved off the simple provider as a result, and nothing said
+so — `docs/output/18-provider-detection.txt` catches it:
+
+```
+spring.cache.type          : (not set)
+resolved CacheManager bean : org.springframework.cache.caffeine.CaffeineCacheManager
+```
+
+A transitive dependency on Hazelcast, added for something unrelated, will do the same thing and
+outrank Redis while it is at it. **Set `spring.cache.type` explicitly in anything you deploy.**
+
+## Per-provider configuration
+
+| Property | Effect |
+|---|---|
+| `spring.cache.type` | `generic`, `jcache`, `hazelcast`, `infinispan`, `couchbase`, `redis`, `caffeine`, `cache2k`, `simple`, `none` |
+| `spring.cache.cache-names` | Creates exactly these caches at startup; anything else fails at the call |
+| `spring.cache.caffeine.spec` | e.g. `maximumSize=500,expireAfterAccess=600s` |
+| `spring.cache.redis.time-to-live` | a `Duration` |
+| `spring.cache.redis.cache-null-values` | default `true` |
+| `spring.cache.redis.key-prefix`, `use-key-prefix` | keyspace hygiene in a shared Redis |
+| `spring.cache.jcache.provider`, `spring.cache.jcache.config` | JSR-107 |
+
+`spring.cache.type=none` gives a `NoOpCacheManager`: every method runs every time, and the
+annotations stay where they are. Useful in tests, and the fastest way to answer "is the cache
+causing this?".
+
+`spring.cache.cache-names` is worth using in production: it turns a typo in a cache name from a
+cache that silently never hits into an `IllegalArgumentException` at the first call.
+
+One caveat — a single `spring.cache.caffeine.spec` applies to **every** cache. Per-cache expiry
+needs your own `CaffeineCacheManager` (or several `CacheManager` beans and `cacheManager = "..."`
+on the operations), which is another argument for one cache name per method.
+
+## Where the auto-configuration lives in Boot 4
+
+`org.springframework.boot.cache.autoconfigure.CacheAutoConfiguration`, shipped in the
+`spring-boot-cache` module. Boot 4 split `spring-boot-autoconfigure` into per-technology modules;
+the Boot 3 coordinate `org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration` no
+longer resolves. `docs/output/16-autoconfiguration.txt` checks both names against the running
+classpath. It matters if you write `@ImportAutoConfiguration` or exclusions by class name.