* Guidelines: Add test for rest_api_init firing before init

Hosts can call rest_get_server() during plugins_loaded, which fires rest_api_init before init priority 10 has had a chance to register the wp_guideline post type. The rest_api_init callbacks in lib/experimental/guidelines/index.php dereference the post type object, so without a defensive guard they fatal (controllers) or trip _doing_it_wrong (register_post_meta).

This test simulates that ordering by unregistering the post type and firing rest_api_init directly.

* Guidelines: Ensure post type is registered before rest_api_init callbacks

init normally fires before rest_api_init, but anything that calls rest_get_server() early (e.g. from plugins_loaded) fires rest_api_init before init priority 10 has had a chance to register the wp_guideline post type. When that happens, the rest_api_init callbacks dereference a null post type object:
  - Gutenberg_Content_Guidelines_REST_Controller and Gutenberg_Content_Guidelines_Revisions_Controller fatal in their parent constructors (WP_REST_Posts_Controller::__construct and WP_REST_Revisions_Controller::__construct).
  - Gutenberg_Guidelines_Post_Type::register_post_meta trips a _doing_it_wrong notice about meta keys enabling revisions support on a subtype that does not support revisions.
Add a single priority-1 rest_api_init guard that registers the post type if it does not yet exist, so all subsequent rest_api_init callbacks see a fully-registered post type regardless of how the REST server was booted.

---------

Co-authored-by: Xavier Lozano Carreras <xavier.lozano.carreras@a8c.com>