Clear the ObjectId cache when deleting ontology objects by SQL (#8213)

## Rationale
Fix stale ObjectIds after ontology objects are deleted by SQL:
recreating a deleted LSID reused its old ObjectId and failed the
`objectproperty` foreign key. This path never invalidated the ObjectId
cache; #8193's more accurate post-commit cache replay now leaves those
ObjectIds cached, which broke `MixtureBatchUpgradeTest` when a batch
edit removes and re-adds its material inputs ([TeamCity
failure](https://teamcity.labkey.org/buildConfiguration/LabKey_Trunk_Internal_Upgrade_UpgradeSetupPostgres/4227772)).

## Related Pull Requests
- #8193

## Changes
- Deleting ontology objects by SQL now invalidates the ObjectId and
property-map caches, like the other delete paths
- The SQL delete runs as one statement that reports exactly which
objects it removed, so only those cache entries are evicted; very large
deletes fall back to clearing the affected containers
- All ontology delete paths share one cache-invalidation helper
- New integration tests cover recreating objects after a SQL delete,
inside and outside a transaction, across containers, and past the
targeted-eviction limit

Tested locally: the new tests fail without the fix and pass with it, and
`OntologyManager`, `CacheReplayCommitTask`, and `DatabaseCache` tests
pass.

## Tasks
- [x] Claude Code Review
- [x] Manual Testing - N/A
- [x] Test Automation

Author: labkey-jeckels