Sanity 3.21 cacheKey API: stale query results after webhook-triggered document updates

After upgrading a project from Sanity 2.x to 3.21, I want to adopt the new cacheKey customization API for client queries while keeping results consistent when documents change. The concern is that queries served from the client-side cache appear to keep returning pre-mutation data even after a document is updated through a webhook-driven pipeline.

The constraints: staleTime and gcTime are currently left at their defaults, and the application relies on webhook notifications from Sanity to signal that content has changed. The interaction between a custom cacheKey and webhook-triggered invalidation is not clearly documented, so it is unclear whether a custom key bypasses the normal invalidation path or merely changes how entries are stored. There is also mention of a skipInvalidation fetch option that may not be stable across releases, which makes relying on it risky.

Assume Sanity client 3.21+ with the default in-memory cache. This can be verified by querying a document, mutating it via the HTTP API, and observing whether the cached payload changes after the expected invalidation window.

Does a custom cacheKey affect how webhook-triggered document updates evict cached query results? What staleTime/gcTime values are recommended when mutations originate outside the client? Is skipInvalidation safe to depend on in 3.21?