'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.

Implements the write-oriented `core/manage-settings` ability that
WP_Settings_Abilities reserved a slot for. It reuses the exposed-settings
snapshot built for `core/settings`, so every setting flagged with
`show_in_abilities` is both readable (`core/settings`) and writable
(`core/manage-settings`), and the input/output schemas reuse the same
per-setting schemas.

The Abilities API validates the input against those schemas (with
`additionalProperties` disabled) before execution, so an invalid or unknown
value aborts the whole call before any option is written -- matching the
all-or-nothing behavior of the REST settings controller. Each accepted value
is sanitized against its schema, stored, then read back and cast for the
response.

Covers registration and writable annotations, an input schema that mirrors
the exposed settings with additionalProperties disabled, updating and
returning correctly typed values, all-or-nothing aborting on an invalid
value (the valid sibling must not persist), rejection of unknown keys and
empty input, the manage_options permission gate, and writing a setting
registered by another plugin.