Guard against a premature DB error in wp_initialize_site()

[lloc]

https://core.trac.wordpress.org/ticket/37685

wp_initialize_site() switched to the new site before its tables existed, letting the switch_blog hook query a nonexistent options table; this suppresses that query and reorders the roles setup so populate_roles() still targets the correct site.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props realloc.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[irozum]

Nice, targeted fix — this closes the one remaining query error from #37685 that survived the 5.1 install_blog() → wp_initialize_site() migration, and it does it by reusing the exact remove_action/add_action guard around switch_to_blog() that wp_is_site_initialized() and WP_Roles::get_roles_data() already use for the same class of problem, so it's consistent with the existing idiom rather than inventing a new one.

I checked out the branch and ran phpcs (clean), PHPStan (no new errors — the two reported errors are pre-existing stale ignore-patterns in comment.php, unrelated to this diff), and the full Tests_Multisite_Site class under the multisite config: 191 tests / 574 assertions, all green, including the two new regression tests.

One thing worth calling out since it's easy to miss: the add_action() placement relative to restore_current_blog() is deliberately the opposite of the pattern in wp_is_site_initialized() (which restores first, then re-hooks). That's correct here rather than a slip — this function actually overwrites the global $wp_roles for the new site via new WP_Roles(), so restore_current_blog() needs the hook back in place before it fires so wp_switch_roles_and_user() re-syncs $wp_roles/current user back to the original site. wp_is_site_initialized() never touches those globals, so it doesn't need that. The new test_wp_initialize_site_restores_global_state() test covers exactly this, which is good given how non-obvious it is from the diff alone.

No blocking concerns from me. Nice catch, and thanks for the regression tests.