Change setting using MCP should fire the correct hook

[wordpressfan]

Based on this comment:
#8482 (comment)

We need to clear the cache exactly as we fire rocket_after_save_options and preserve expected side effects such as validation, cache clearing, and internal consistency.

We need to list all the actions need to happen when we save the options that clear the cache and never do anything with database options for example.

[remyperona]

This needs to be investigated and replicated before anything, the cache clear should happen normally:

The set-option ability does not clear the cache itself, but the cache is cleared as a side effect of the option write — through the same hook path the normal settings form uses.

The chain:

1. SetOption::execute()callsupdate_rocket_option()(SetOption.php:254) — it has no explicit purge call.
2. update_rocket_option()→Options::set('settings', …)→update_option('wp_rocket_settings', …)(options.php:47,class-options.php:79).
3. WordPress firesupdate_option_wp_rocket_settings, which is wired torocket_after_save_options()(options.php:83).
4. In that handler, when the options hash differs, it callsrocket_clean_domain()— a full page-cache purge — and firesrocket_options_changed(options.php:69-81).

So changing a value through the ability purges the full domain cache, just like saving the settings page.

[Khadreal]

The chain is broken in main.php that requires inc/admin/options.php which defines hooks rocket_after_save_options is loaded only when is_admin() is true. MCP requests never satisfy that condition, so the function is never defined or hooked.

Scope a solution ✅

In SetOption::execute we should add explicit cache clearing logic which would run right after the option write is successful. This should replicate only cache clearing subset of what rocket_after_save_options() normally does.

Estimation ✅

Small [S]