Revisions: render the author for users who cannot edit users - #82306

What?

Closes #82305

Renders a revision's author for users who cannot edit_users, by supplying the author's display name and avatars with the revision instead of resolving them through a separate user request.

Why?

AuthorView resolves a revision's author with getEntityRecord( 'root', 'user', authorId ). The root/user entity is fixed to context: 'edit', and WP_REST_Users_Controller::get_item_permissions_check() refuses that context unless the caller can edit_user the target, which maps to the administrator-only edit_users capability.

Every other role therefore gets a 403 rest_forbidden_context and the row renders as an empty name next to the fallback person icon. Viewers still see their own row, because the controller short-circuits when the caller is the target. Captured as an editor-role user on one page load:

200  /wp/v2/users/2?context=view&_fields=id,name   <- post author panel, fine
403  /wp/v2/users/2?context=edit                   <- revisions sidebar, blocked
200  /wp/v2/users/3?context=edit                   <- self, allowed

The obvious fix is to pass { context: 'view' } at the call site, and it does work for the common case. I did not take that route, because a second gate in the same permission check (count_user_posts()) still refuses a user who has never published, even in view context. Any approach that resolves the author through /wp/v2/users/<id> hits that gate, _embed included, since context=embed only skips the first one. That leaves a blank name for a revision authored by someone with no published posts.

How?

Supplies the author with the revision, mirroring WP_REST_Comments_Controller, which has exposed author_name and author_avatar_urls directly for exactly this reason since 4.7. The server decides what to expose, the client never asks about a user, and the permission question does not arise.

• Gutenberg_REST_Revisions_Controller_7_2 (new, in lib/compat/wordpress-7.2/) extends Gutenberg_REST_Revisions_Controller and exposes author_name and author_avatar_urls alongside the existing numeric author, plus a get_item_schema() override declaring them. It calls the parent's prepare_item_for_response() and adds the two fields to the response rather than duplicating the method, so the 7.0 nested _fields handling stays in one place. The avatar block follows the comments controller, including the show_avatars guard and the rest_get_avatar_sizes() loop.
• lib/compat/wordpress-7.2/rest-api.php points revisions_rest_controller_class at the new class at priority 11, superseding the 7.0 override while leaving a controller a site set itself alone.
• buildRevisionsPageQuery requests the two new fields.
• AuthorView prefers them and skips the fetch when they are present, falling back to the existing fetch and _embedded paths otherwise, so it behaves unchanged wherever the fields are absent.

This also removes one REST request per distinct revision author. In the repro below, the revisions sidebar goes from 3 user requests to 0.

Two incidental fixes:

• Drops a comment claiming the fetch is free because getElements already populated the store. Records are keyed by the query's context: getElements uses getEntityRecords with context: 'view' and writes the "view" bucket, while AuthorView reads the "default" bucket. They never share an entry, so the request always happened. getElements also does not run in the revisions inspector at all.
• Adds author_name and author_avatar_urls to BasePost.

Testing Instructions

1. Fresh WordPress with this branch active.
2. Create an administrator (alice) and an editor (bob).
3. Publish a post as alice, then edit and save it twice more as alice.
4. Edit and save the same post once as bob.
5. As bob, open the post, enter the revisions view, and open the settings sidebar.
6. Every revision should show its author's name and avatar. On trunk, alice's two revisions show an empty name and a generic person icon.
7. Repeat as alice to confirm no regression for administrators.
8. Optionally add a user with no published posts, have them save a revision, and confirm their name renders too. That case is not fixed by switching the call site to context: 'view'.

Verified against WordPress 7.2-alpha with an editor-role viewer, four revisions by three authors, one of whom has no published posts:

Also checked: view/edit/embed contexts, _fields still honoured when the new fields are not requested, title.raw sub-field filtering unaffected, show_avatars = 0 omits author_avatar_urls from both the response and the schema, and HEAD still returns an empty body.

Testing Instructions for Keyboard

No UI or interaction changes. The revision list is reachable and operable exactly as before; only the rendered author text and avatar differ.

Screenshots or screencast

Before

After