Verify FSE invalidation end-to-end against staging with plugin 1.7.0

[kuuak]

Parent

#132

What to build

End-to-end proof of the full loop with no manual step: an editor saves a template part in the WordPress site editor, and the change appears on the frontend.

Everything up to this point can be verified by calling the invalidation endpoint by hand. This ticket closes the loop with the WordPress side, which fires the invalidation automatically on FSE changes.

Verification should run against a real project with a substantial snapshot — tipee.ch staging is the reference environment, with a snapshot spanning thirteen templates and over a thousand blocks.

Equally important is confirming what does not fire: navigation menu edits are deliberately excluded, because menu items are resolved at request time and are absent from the snapshot by design. A menu edit triggering snapshot invalidation would be pure waste and indicates a mis-wired trigger.

Acceptance criteria

• Editing a template part in the site editor updates the frontend with no manual invalidation and no rebuild
• Resetting a template to its theme default updates the frontend
• Switching themes updates the frontend
• Editing a navigation menu does not trigger snapshot invalidation
• Saving a regular page or post still revalidates through the existing path-based route, unchanged
• A single site-editor save results in one invalidation request, not several

Blocked by

• Invalidate the FSE snapshot on demand via a revalidation endpoint #135
• Externally: Revalidate Next.js FSE snapshot when templates or template parts change nextjs-revalidate#30 and the v1.7.0 plugin release