Settings Get: a comma-separated fields filter is ignored when the ability is executed directly #1160

Description

core/settings-get ignores its fields filter when the value is a comma-separated string and the ability is executed directly (PHP, WP-CLI, or any in-process caller). It returns every exposed setting where two were asked for, and reports no error.

The input schema declares fields as an array of strings. Schema validation accepts a comma-separated string for an array, so "blogname,siteurl" passes. execute_get_settings() in includes/Abilities/Settings/Settings.php then requires is_array() and falls back to an empty filter, which means "all settings":

$fields = isset( $input['fields'] ) && is_array( $input['fields'] ) ? $input['fields'] : array();

I expect input that passes validation to be honored, so a comma-separated fields value returns only the named settings. core/users-query and core/content-query already read list inputs this way (normalize_string_list() in Users.php, wp_parse_list() in Content.php).

The REST route is not affected. A request such as GET …/core/settings-get/run?input[fields]=blogname,siteurl returns the two settings, because the REST layer turns the string into an array before the ability runs.

Step-by-step reproduction instructions

1. Enable the Custom Abilities experiment under Settings > AI, which registers core/settings-get.
2. Run the ability directly with a comma-separated fields value:

wp eval 'wp_set_current_user( 1 ); echo count( wp_get_ability( "core/settings-get" )->execute( array( "fields" => "blogname,siteurl" ) ) );'

3. Run it again with an array:

wp eval 'wp_set_current_user( 1 ); echo count( wp_get_ability( "core/settings-get" )->execute( array( "fields" => array( "blogname", "siteurl" ) ) ) );'

Expected: both print 2.

Actual: the first prints the number of all exposed settings (19 on my site). The second prints 2.

Screenshots, screen recording, code snippet

csv string: 19 settings
array:      2 settings

Over REST, as an Administrator, both forms return 2 settings:

?input[fields]=blogname,siteurl                          -> blogname, siteurl
?input[fields][]=blogname&input[fields][]=siteurl        -> blogname, siteurl

Suggested fix: read fields with wp_parse_list() and keep the string items, as Content.php does.

Environment info

• WordPress 7.1.3 (wp-env, PHP 8.3.35), Twenty Twenty-One
• AI plugin: develop at 4fc2d4a (1.4.0)
• AI Provider for OpenAI 1.2.0 and AI Provider for Google 1.2.0

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except the AI plugin.

• Yes (only the provider plugins listed above and the repo's tests/e2e-testing plugin were active)

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure