[labkey-tchad]

Rationale

Filling some testing gaps found by Claude:

1. No end-to-end test of pruning through DatabaseCache. The whole design depends on BlockingDatabaseCache.load() and TransactionCache passing the same _databaseCache object as the Op.cache key. They do today: TransactionCache
   is built with this. But only the string-keyed unit tests exercise pruning. If either side started passing getCache() or the wrapper instead, every removal would stop dropping reloads, and no test would fail. Suggested test
   in DatabaseCache.TestCase, using a BlockingDatabaseCache with a counting loader:
   • Inside a transaction, call get("a") (miss), remove("a"), get("b"), then clear(), then get("c"), and commit.
   • Assert that the replay task holds only the clear and the reload of c.
   • Assert that after commit the shared cache holds only c, and the loader ran exactly once more after commit.
2. Reloads are never shown to run after commit. testDatabaseCacheTransactionLimit commits but checks nothing afterwards. Nothing proves the () -> get(key, argument, loader) lambda runs or fills the shared cache. This was also
   untested before the PR, but this PR rewrites that path. Two asserts after transaction.commit() would cover it: the shared cache has maxSize keys, and the loader call count is right.
3. No automated rollback test. The PR lists "Transaction rollback doesn't update cache" as manually tested. A test that loads and removes inside a transaction, closes it without committing, and asserts the shared cache is
   unchanged would lock that in.
4. Remove → reload → remove of one key isn't tested. The second remove drops the reload in between, and its own add is a duplicate, so the first REMOVE keeps its earlier position. The result is correct, but this exact path in
   remove() has no test. It would take three lines in CacheReplayCommitTask.TestCase.
5. Nothing tests registering an operation while the replay runs. The comment in run() says operations can be registered during replay when commitAndKeepConnection() runs on an outer transaction. A unit test where one operation
   calls task.reload(...) on the same task would pin the copy that prevents a ConcurrentModificationException. Without it, a later "simplification" that drops the copy would pass every test.