Invalidate the FSE snapshot on demand via a revalidation endpoint

[kuuak]

Parent

#132

What to build

A secret-protected endpoint that invalidates the cached FSE snapshot on demand, so an editor's template change reaches the frontend without a rebuild.

This is the payoff of the whole effort: edit a template in WordPress, call the endpoint, see the change live. The endpoint invalidates the snapshot's cache tag and returns — it does not warm anything. Invalidation is cheap and O(1); warming is the expensive, separate concern under research in #130, and fanning out fetches here would not scale to sites with thousands of pages.

Authentication reuses the same shared secret and query-argument convention as the existing revalidation endpoint, so no new auth surface is introduced. The path must match the default the WordPress plugin will ship with (see superhuit-agency/nextjs-revalidate#30).

This ticket also settles an open question that shapes the design: whether invalidating the snapshot's tag reaches the cached full-page entries of pages already rendered, or only the cached snapshot itself. If it does not propagate, a single ping is insufficient and additional page-level invalidation is required — record the finding in #130 and raise follow-up work rather than expanding this ticket.

Acceptance criteria

• A request with a valid secret returns success; a wrong or missing secret is rejected as unauthorised
• After a template is edited in WordPress and the endpoint is called, the change is visible on the frontend with no rebuild and no process restart
• The endpoint performs no page warming and issues no per-page fan-out
• The response shape is consistent with the existing revalidation endpoint
• Determined and recorded as a comment on Research: cheap cache invalidation vs selective warming for large sites #130: does tag invalidation reach already-rendered full-page cache entries, or only the cached snapshot?

Blocked by

• Serve the FSE snapshot from a runtime cache instead of the build #134