- Sanitize ability input against the input schema in both callbacks, since
  the Abilities API validates but does not coerce REST GET input (booleans
  arrive as 'true', arrays as CSV strings) and the strict normalizers were
  silently dropping those filters.
- Return a fully redacted user as an object so it serializes as {} rather
  than [] and honors the declared output type.
- Always declare avatar_urls in the schemas and honor show_avatars when
  formatting instead, since the registered schemas are a registration-time
  snapshot while the option is re-read at call time.
- Extract resolve_readable_user() so the single-user authorization decision
  is implemented once and shared by the permission and execute callbacks.

Adversarial review of the previous commit surfaced defects in the
schema-based sanitize pass, so coercion now lives in the normalizers:

- rest_sanitize_value_from_schema() embeds property-level WP_Errors (an
  include list of '1' and '01' validates as unique strings but sanitizes
  to a WP_Error after integer coercion, silently dropping the filter),
  discards schema-valid stdClass input, falls back to raw input when the
  call-time schema drifts from the registration-time snapshot, and
  rebuilds the input schema on every call.
- normalize_string_list() and normalize_include() now accept the CSV
  strings REST GET delivers (the latter via wp_parse_id_list(), which
  also deduplicates string-distinct IDs), normalize_has_published_posts()
  accepts the string forms of true, and stdClass input is treated as its
  array form.
- The id field is always included, matching the REST users controller
  where id is present in every context; a fully redacted result now
  returns the user ID instead of an empty object, which REST
  post-processing (_fields/_embed) cannot handle at the top level.
- Coverage extended: string-duplicate include IDs, numeric-string
  scalars, and object input.

A prior commit removed normalize_per_page(), normalize_string_list(), and
normalize_include() but left their call sites, so PHPStan and the PHP/E2E
suites failed with "Call to undefined method". Restore the normalizers.

Also normalize the username lookup with sanitize_user() so every single-user
lookup field is normalized alongside id (absint) and email (sanitize_email),
keep the slug lookup on the raw nicename to match the REST users controller
(non-canonical nicenames must resolve), and note that collection total/
total_pages may exceed the returned users when the multisite membership guard
skips rows.

The normalizer restore reverted a `phpcs:ignore` that suppresses a Slevomat
false positive (a multi-line array constant read as a multi-constant
definition) on DEFAULT_FIELDS. Restore the annotation so PHPCS passes.

The roles field was returned to any caller with list_users, even for users
they cannot edit. list_users grants no edit rights, so this disclosed the
site's privilege map to a list_users-only role. Gate roles on the same
is-self-or-can-edit check as the other sensitive fields, matching the REST
users controller, where roles is an edit-context field and non-editable rows
are dropped from collections.

The output schema's roles enum was captured at ability registration. A role
registered afterwards is still held by a returned user, so format_user emits
it, but the frozen enum rejects it during output validation and fails the
whole call with ability_invalid_output. Drop the enum from the output roles
items (plain strings, matching the REST users controller); the input roles
enum, which is re-resolved at call time, is unaffected.

The collection loop post-filtered rows by is_user_member_of_site() while
total/total_pages came from the unfiltered WP_User_Query. On multisite a bare
collection query (no roles/has_published_posts) is network-wide, so a
list_users caller got an inflated total and short, near-empty pages.

Drop the per-row membership filter so users, total and total_pages all derive
from the same query, matching WP_REST_Users_Controller::get_items (no per-row
membership check, get_total() reported directly). Single-user lookups keep the
membership check, matching the controller's get_user(). No-op on single site,
where the guard was already always-true.

The comment claimed a bare collection query is network-wide on multisite,
but WP_User_Query scopes results to the current blog via the capabilities
meta clause it adds whenever blog_id (defaulted to the current blog) is set,
even with no role/has_published_posts filter. Correct the note to describe
the actual site-scoping; no behavior change.

The `is_public_author()` docblock said the method checks for published posts.
That is not what it does. `count_user_posts()` defaults to `$public_only =
false`, so a private post also counts for a caller who holds
`read_private_posts` for that post type.

Collection mode is filtered by `WP_User_Query` with `has_published_posts`, which
matches published posts only. So an editor can resolve an author whose posts are
all private through a single-user lookup, but will never find that author in a
collection.

This keeps the current behavior, which matches the REST users controller. It
exposes nothing new, because an editor who can read the private post already
sees its author through the post itself. The docblock now describes the rule,
and a new test pins all three legs: the editor resolves the author, the
collection omits them, and a subscriber is denied.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The comment above the `include` query argument said the default ordering is kept
"regardless of the requested order". There is no order input, so that clause
described something the ability does not have. It was left over from dropping
`orderby => include` in e01b49d.

The comment now says what is actually being avoided. A new test locks the
behavior in: it runs the same include set in both orders and expects the results
in user login order both times. Adding `orderby => include` back makes it fail.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Peter pointed out that `public => true` does not mean a post type can be viewed
on the front end, so the ability switched to is_post_type_viewable(). One path
still slipped through. Passing `has_published_posts => true` straight to
WP_User_Query makes core resolve the list itself, as
`get_post_types( array( 'public' => true ) )`, which is the very set Peter warned
about.

The effect: an author whose only published post used a post type registered with
`public => true, publicly_queryable => false` was matched by a boolean filter,
even though the ability rejects that post type in the input enum, in collection
mode for callers who cannot list users, and in the single-user lookup.

Both branches now resolve the post types the same way, so `true` and an explicit
list mean the same thing. Resolving at call time also picks up post types that
were registered or unregistered after the input schema was built, which was
Peter's other point.

A new test registers the post type from his gist and checks all three paths.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>