Abilities API: Register settings metadata during init

[gziolo]

Follow-up to WordPress#12141, targeting its source branch.

The settings ability captures registered settings when the abilities registry is first accessed after init. Registering core metadata on rest_api_init or registering it again during ability initialization makes the result depend on which API runs first.

This change registers core settings metadata on init and removes _wp_register_initial_settings_for_abilities(). It preserves the admin allowed-options lists so metadata registration does not change which options settings forms can save, including the email confirmation flow.

Plugin settings exposed through show_in_abilities must also be registered on init or earlier, with argument filters attached before registration. register_setting() emits an incorrect usage notice for later registrations, using the exposure value after filters run. The notice does not prevent registration.

Tests cover registration timing, filtered exposure, custom public names, core metadata availability, and preservation of admin allowed-options lists. Existing ability tests now use the same registration timing contract. Comments and docblocks explain the expected behavior and its purpose.

Validation:

• Targeted PHPUnit coverage for settings abilities, core abilities, option registration, and the REST settings controller passed (88 tests). After the final test cleanup, the settings ability class passed again (22 tests, 52 assertions).
• The broader option,abilities-api groups passed with no failures (810 tests, 3 skips, and one existing PHPUnit warning).
• PHP_CodeSniffer passed for all five changed files; git diff --check passed.
• The final documentation pass changed only comments, whitespace, and two data provider labels; PHPUnit was not rerun for that pass.

PHPUnit used a temporary local bootstrap connected to the test database. Targeted filter: Tests_Abilities_API_WpRegisterCore(SettingsGetAbility|Abilities)|Tests_Option_Registration|WP_Test_REST_Settings_Controller. Broader run: --group option,abilities-api.

Trac ticket: https://core.trac.wordpress.org/ticket/64605

Use of AI Tools

AI assistance: Yes. Tool: OpenAI Codex. Used for implementation, regression tests, documentation, validation, and this PR description, following the contributor's design direction and iterative feedback.

[semanticdiff-com]

Review changes with  

[gziolo]

Moving register_initial_settings() to init changes behavior for every request, not only for abilities:

1. Filters added later stop working. For example, a register_setting_args filter added on rest_api_init no longer changes core settings in /wp/v2/settings.
2. Defaults apply everywhere. For example, get_option( 'WPLANG' ) now returns 'en_US' and not false. d7120a2 - presents the issue and potential workaround.

The root problem is that register_setting() does several things at once. It stores the metadata, adds a default option filter, and adds the option to the options forms.

Long term, I would love to split this:

• Register only the settings metadata on init, so any API can read it.
• Move the parts tied to the REST API to rest_api_init.
• Move the parts tied to admin forms, like $new_allowed_options, to admin_init.

This is a bigger Settings API change, so it should have its own Trac ticket. For now, let's keep the current approach in WordPress#12141 and bring over the useful tests from here.