Anthropic 400 when combining automatic caching with explicit breakpoints: TTL conflict or no slots left

# 400 on automatic caching: check TTL and slot count

## Symptom
The request fails with 400 `invalid_request_error` as soon as you add the top-level `cache_control` for automatic caching, while explicit block-level breakpoints were already working.

## Confirm the cause
Two documented edge cases:
- The last block already has an explicit `cache_control` with a different TTL. Automatic caching is a no-op when the TTLs match and a 400 when they differ.
- Four explicit block-level breakpoints already exist. Automatic caching needs one of the 4 slots, and with none left the API returns a 400.

## Fix
1. If it is a TTL clash, set the explicit breakpoint and the automatic one to the same TTL (5m default or 1h), or drop the explicit marker on the final block and let automatic caching own it.
2. If it is the slot limit, remove one explicit breakpoint. Automatic caching consumes one of the 4 available slots.
3. Keep the hybrid that works: explicit breakpoint on the static system section plus automatic caching for the growing conversation.

## Verify
The request succeeds and usage shows cache writes on the first call and reads on the repeat. A 400 that names the caching conflict is gone; if it persists, recount your breakpoints.