Issue #3616990: Stop caching the two entities that are only ever written under the lock

Not proposed for merge yet. Pushed so CI runs the whole suite against the change, because the interesting question is which tests notice.

The change

persistent_cache: FALSE on yoyaku_booking and yoyaku_transaction. Neither is read the way a persistent entity cache serves: both are written on every hold, release, confirm and expiry, and both are read through queries and aggregates rather than by id, so the cache serves almost nothing while paying an invalidation per write. That invalidation is a DELETE issued from inside the hold transaction, while the slot row lock is held.

The read-hot, write-cold types keep their cache: venue, place, grade, section, resource, tariff, slot and configuration are operator-edited and are exactly what a persistent entity cache is for.

The measurement

Over HTTP against the database cache backend, log taken around holdInTransaction() only, cache warmed by a preceding hold, five samples each way and every sample identical:

	queries a hold	of which cache_entity
cache on, as today	35	4: SELECT, DELETE, SELECT, DELETE
persistent_cache: FALSE	33	2, both SELECT

So it removes exactly the two DELETEs, and both run inside the lock. The surviving SELECTs belong to types that stay cached.

Why the earlier measurement said nothing

An earlier note claimed this cost nothing because every query budget class passed unchanged. True, and blind: KernelTestBase puts every cache bin on the memory backend, so a cache delete is not a database query in a kernel test and no budget class could have seen one. That rule is now written down beside the others in docs/performance.md.

What this run is for

Two queries is a real number and not a large one, and what would actually justify the change is the share of the lock's HOLD TIME those deletes account for, which nobody has measured. The issue stays postponed on that. What CI can answer now is the other half: whether anything in the suite depends on these entities being cached. A read that was being served from the cache and now goes to the database would show up as a budget class failing, and that is worth knowing before this is picked up again.