[6.x] Fix Custom Invalidator background recache

[marcorieser]

Fixes #15025

Problem

When background_recache is enabled, a custom Invalidator class never runs its invalidate() logic on entry save.

Invalidate::refreshEntry() calls Invalidator::refresh(). In DefaultInvalidator::refresh(), when background_recache was off, it delegated to $this->invalidate($item) — so a subclass overriding invalidate() fired correctly. When background_recache was on, it skipped invalidate() entirely and recomputed URLs itself, calling $this->cacher->refreshUrls(...) directly. Any custom Invalidator subclass overriding invalidate() (the documented extension point) was silently never called in this mode.

Fix

DefaultInvalidator::refresh() now always delegates through invalidate(), guarded by a $refreshing flag. invalidate() uses that flag to decide whether to call cacher->refreshUrls() (soft, background re-cache) or cacher->invalidateUrls() / cacher->flush() (hard invalidate), preserving existing behavior for both the default flow and deletions, while letting custom subclasses actually execute in all cases.

The flag is set/reset around the delegated call via try/finally (so it can't get stuck on an exception) and saves/restores its previous value rather than resetting to false unconditionally (so nested refresh()/invalidate() calls, e.g. from a custom Invalidator that itself calls refresh() on a related item, don't clobber an in-progress outer call).

Tests

Added a unit test in DefaultInvalidatorTest.php asserting a custom invalidate() override is exercised when background_recache is enabled.