fix(entry-actions): invalidate page-tree index on delete

deleteEntry did cache.deleteAll() but not Cache::invalidateCache(), so under
cache.check.method: folder the deleted entry lingered in the pages index and the
feed re-rendered it (image-less) on reload. Mirror the create-path fix. See
docs/solutions/integration-issues/grav-deleteall-doesnt-invalidate-page-tree-index.md

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mpdu3Dt1iVoozHwAMyjrbn

plugins/entry-actions/classes/EntryActionsApiController.php

@@ -1,6 +1,7 @@
 <?php
 namespace Grav\Plugin\EntryActions;
 
+use Grav\Common\Cache;
 use Grav\Common\Filesystem\Folder;
 use Grav\Plugin\Api\Controllers\AbstractApiController;
 use Grav\Plugin\Api\Exceptions\ApiException;
@@ -62,7 +63,14 @@ class EntryActionsApiController extends AbstractApiController
         }
 
         Folder::delete($path);
+        // deleteAll() drops the cache stores but does NOT rebuild Grav's page-tree
+        // index (keyed on folderHash, which doesn't change on child removal under
+        // cache.check.method: folder). Without invalidateCache() the deleted entry
+        // lingers in the index and the feed re-renders it — now image-less — on the
+        // next load. Mirrors the create-path fix in the cache-on-save plugin. See
+        // docs/solutions/integration-issues/grav-deleteall-doesnt-invalidate-page-tree-index.md
         $this->grav['cache']->deleteAll();
+        Cache::invalidateCache();
         // Audit trail: entry deletion is destructive and owner-only — record who
         // did it and to what, so an unexpected disappearance is traceable.
         $this->grav['log']->info(sprintf('entry-actions: owner "%s" deleted entry "%s"', $user->username, $slug));