'settings' reads more naturally than 'slugs' for filtering an abilities-exposed
settings map by name.

… tests

Register a setting with show_in_abilities and assert it is exposed in the
ability's input enum, output schema, and execute output.

- Simplify the input schema: replace the group-XOR-name `oneOf` with optional,
  combinable `group` and `fields` filters (rename `slugs` -> `fields`, matching
  core/get-site-info). Default to an empty object so the type:object schema default
  serializes as {}.
- Memoize the exposed settings so the input/output schema and execute() derive from a
  single walk of get_registered_settings().
- Cast object-typed values to objects so they serialize as {} (not []) and satisfy the
  output schema validated by execute().
- Harden value handling against loosely-typed registration data.
- Tests: assert keys order-insensitively and cover combined group+fields filtering.

…cblock

The $groups and $field_names params are sequential string lists
(array_keys() and an appended array), so list<string> is the precise
type rather than string[].

…ettings()

The exposed-settings cache is always populated in register_get_settings()
before the ability is registered, so the recompute fallback was dead code.
Read the cache directly and keep a defensive null guard so the unexpected
case is explicit rather than silently recomputing.

…tract

The core/settings ability snapshots the exposed settings when it registers
on wp_abilities_api_init, so a setting must be registered before that hook
fires to be exposed. Note this on the show_in_abilities register_setting()
argument so integrators know their register_setting() has to run earlier.

Make WP_Settings_Abilities final and tighten member visibility so the
intended surface is enforced rather than only documented via @access
private. Only the externally-invoked entry points remain public
(register(), execute_get_settings(), has_permission()); register_get_settings()
and the shared helpers become private, and CATEGORY becomes a private const.
Method bodies and the static cache are unchanged.

Move register() and the ability callbacks (execute_get_settings(),
has_permission()) from public static to public methods, and the internal
helpers to private methods; the exposed-settings cache becomes an instance
property. wp_register_core_abilities() now registers the ability via
( new WP_Settings_Abilities() )->register(), reducing the static surface
of this @access private class.

…y.php

Co-authored-by: Greg Ziółkowski <[email protected]>

Aligns the core/get-site-info, core/get-user-info, and
core/get-environment-info input schema defaults with core/read-settings:
(object) array() instead of array(), so the serialized default is {},
consistent with type:object.

Per review, all the tests added by this PR should reference the ticket
that introduces the ability.

…apshots them.

The wp_abilities_api_init hook fires lazily on first use of the abilities
registry, which is not ordered relative to rest_api_init (where core
registers its initial settings) and can happen without it entirely, e.g.
on cron or WP-CLI. When the registry initialized first, core/read-settings
captured an empty settings snapshot for the rest of the request.

Ensure register_initial_settings() has run before the snapshot is
computed, and register the ability under the previously broken ordering
in the tests so they cover the regression.