Fix N+1 styling & evaluation bottleneck during ActionGroup rendering in tables.

[emrullahardc]

Description

Fixes severe N+1 styling & evaluation bottleneck during ActionGroup rendering in tables.

Previously, when actions were placed inside an ActionGroup in tables, the trait CanBeHidden would repetitively evaluate closures and perform Gate authorization checks up to 3-6 times per individual action for the exact same table row. This mathematically resulted in hundreds of excessive and completely redundant checks (e.g., 50 rows * 3 actions inside a dropdown generated approximately 870 Gate checks instead of the absolute theoretical minimum of 150 checks).

This PR solves this bottleneck by implementing an Instance-Level Caching (Memoization) mechanism safely attached to the cloned component instance lifecycle.

• Internal Action state queries (isHidden / isHiddenInGroup) have been smartly cached via simple ?bool computed properties.
• Completely respects Filament's dynamic toHtml lifecycle. The cache naturally stays fresh per table-row because Filament handles context isolation via cloning action instances per row.
• Bulletproof Cache Invalidation: Handled dynamic mutations automatically via flushHiddenCache(). Since records and visibility states can be mutated manually before evaluation (e.g., ->record(), ->hidden(), ->visible()), the state cache gracefully invalidates itself, cascading down dynamically to any inner actions inside an ActionGroup to ensure no stale authorizations or evaluations are rendered ever.

Because of this, rendering complex ActionGroups on bulk lists is now extremely lightweight and triggers the exact mathematical minimum of Gate checks.

Visual changes

Before applying the cache optimization (870+ duplicate Gate queries detected):

After the Instance-Level Rendering Optimization (reduced to ideal minimum):

Functional changes

• Code style has been fixed by running the composer cs command.
• Changes have been tested to not break existing functionality.
• Documentation is up-to-date (N/A).

[fatihalp]

it's huge performance impact @emrullahardc

[danharrin]

Unfortunately this is not a safe change to merge, actions could be hidden based on many different outside conditions like properties on a Livewire component or arguments passed to actions, and I think this would make the checks become stale.