Commit transactions explicitly instead of letting them go out of scope

Eight startTransaction() sites commit by letting the Transaction object go out of scope, which is deprecated in drupal:11.5.0 and removed in drupal:13.0.0. Core wants Transaction::commitOrRelease() called explicitly instead. The sites are BookingManager twice, TransactionManager, SlotSeats, the concurrency test controller and RollbacksTest.

It is not a Drupal 12 blocker, which is why it is here rather than in #3618644: Declare Drupal 12 support, and run the whole suite against it. Removal is in 13, so the Drupal 12 claim stands without it; it fails the next-major lane only because run-tests.sh adds --fail-on-deprecation on core main, and it is ignored there with that reasoning written beside it in .deprecation-ignore.txt. Removing that line is part of this issue.

Why it wants its own review. This is the commit path of every hold and every release the engine writes, under the slot locks. An out-of-order rollback in this same code once masked every cause of a fault that turned 1,360 requests into HTTP 500s, and a Transaction destroyed without an explicit commit COMMITS, which is exactly the behavior being converted: a mistake here does not fail loudly, it writes when it should not have. So the change wants reading against the locking design rather than folding into a compatibility branch, and it wants the load rig run before and after rather than a green test suite alone.

What to watch for while doing it. Every path out of the block has to be accounted for, the early returns and the throws included, since that is what the implicit commit was quietly covering. commitOrRelease() on a transaction that a nested one has already rolled back must not be the thing that reports the failure, and the existing rollBack() calls stay exactly where they are: none of them is redundant.

AI-Generated: Yes (Claude Code found this on the Drupal 12 lane and drafted this summary. I reviewed it before posting; no code is written for it yet.)