getCacheTags() unnecessarily initializes style plugin, causing PluginNotFoundException after cache rebuilds

Problem/Motivation

The views_custom_cache_tag module's getCacheTags() method unconditionally calls $view->getStyle() to resolve tokens in custom cache tag strings. However, this causes
unnecessary instantiation of the style plugin (and via Views internals, the row plugin) even when the configured custom tag string contains no tokens that need resolving.

When the plugin definition cache is in a transient bad state immediately after a Pantheon cache rebuild/clear, this unconditional instantiation can trigger a PluginNotFoundException in
EntityRow::init(), with an empty entity type string.

Real-world impact: On a Drupal 11 / Pantheon production site, this issue caused ~89% (3,509 out of 3,984) of watchdog errors within an 18-minute window following a Pantheon deploy cache
flush. Every page view that executed a View with a custom cache tag resulted in this exception, making the site effectively broken until the cache recovered.

Steps to reproduce

1. Configure a View with the views_custom_cache_tag module enabled.
2. Set a static (non-token) custom cache tag string in the View display settings (e.g., my_custom_tag).
3. Perform a full cache clear on Pantheon (or equivalent cache rebuild), ensuring the plugin definition cache is temporarily in a bad state.
4. Load any page that executes the View.
5. Observe the PluginNotFoundException: The "" entity type does not exist error in EntityRow::init().

Note: This is most easily reproduced on a Pantheon environment immediately after a deploy cache flush, when plugin caches are temporarily out of sync. On local DDEV, the recovery is often
too fast to catch easily.

Proposed resolution

In the getCacheTags() method, check whether the configured custom tag string contains any tokens (e.g., [view:*] patterns) that require resolving before calling
$view->getStyle(). If the tag string is a plain static string with no tokens, skip the getStyle() call entirely and return the tag directly.

This avoids the unnecessary plugin instantiation for the common case where the custom tag is a static string, while preserving the current behavior for dynamic token-based tags.

Remaining tasks

• [ ] Confirm reproduction and root cause
• [ ] Write the fix to skip getStyle() for static (non-token) custom tags
• [ ] Add test coverage for both static and token-based tags
• [ ] Review and merge

User interface changes

None

API changes

None

Data model changes

None

Note: A merge request with the proposed fix will follow.