…dpoints

Adds canUser to the hydration set with one spec per post-type collection
(attachment, page, wp_block, wp_template). PHP issues a single internal
OPTIONS per resource; the JS-side hydrator parses the Allow header and
fans it out across all four ALLOWED_RESOURCE_ACTIONS, populating both
the userPermissions cache and the canUser resolution metadata so none
of the four resolver invocations fire.

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

Adds:
- getEntitiesConfig( 'root' )           → OPTIONS /wp/v2/settings
- getEntityRecord( 'root', 'site' )     → GET /wp/v2/settings

Extracts siteEntityFromResponse from loadSiteEntity (mirroring the
postType/taxonomy refactors) so the JS-side hydrator can build the site
entity config from a preloaded OPTIONS response synchronously. PHP
relaxes the getEntityRecord arg check to allow a 2-arg shape for the
keyless site entity.

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

Adds three more resolvers:
- getAutosaves( postType, postId )              → /wp/v2/{rest_base}/{id}/autosaves?context=edit
- __experimentalGetCurrentThemeBaseGlobalStyles → /wp/v2/global-styles/themes/{stylesheet}?context=view
- __experimentalGetCurrentThemeGlobalStylesVariations → /wp/v2/global-styles/themes/{stylesheet}/variations?context=view

The two theme-global-styles selectors take no args, but their receive-
actions need the stylesheet. PHP knows the active stylesheet via
get_stylesheet() and passes it through as an extra field on the
hydration entry; the JS-side hydrator pulls it from there.

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

Adds:
- getEntityRecord( 'root', 'globalStyles', $id ) → /wp/v2/global-styles/$id?context=edit|view
- canUser for the same resource              → OPTIONS /wp/v2/global-styles/$id

The PHP canUser case now also handles root-kind entities whose REST
base is known PHP-side. The getEntityRecord context for global styles
mirrors the legacy preload: `edit` if the user can edit_theme_options,
`view` otherwise.

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

The path-based preload filter now returns an empty array — any remaining
startup fetches go through the network. Anything the editor still needs
at boot becomes a concrete to-do for migration to the selector-keyed
hydration flow. WP core skips emitting createPreloadingMiddleware
entirely when the array is empty, so the inline-script tag disappears.

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

- getCurrentTheme()             → /wp/v2/themes?context=edit&status=active
- getBlockPatternCategories()   → /wp/v2/block-patterns/categories

The getCurrentTheme resolver normally fetches the active-themes list
and picks [0] before dispatching `receiveCurrentTheme`; the JS-side
hydrator does the same. getBlockPatternCategories dispatches the raw
RECEIVE_BLOCK_PATTERN_CATEGORIES action inline (no named action
creator).

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

Two follow-up fixes for the getCurrentTheme migration:

1. The getCurrentTheme selector reads `state.currentTheme` (just the
   stylesheet) and then looks the record up in `entities.records`.
   `receiveCurrentTheme` only sets the stylesheet, so the record needs
   to be in the entities store too. Hydration now dispatches
   `receiveEntityRecords( 'root', 'theme', themes, { status: 'active' } )`
   alongside `receiveCurrentTheme` and marks the inner getEntityRecords
   resolution finished.

2. `__experimentalGetCurrentGlobalStylesId` resolver internally awaits
   `resolveSelect.getEntityRecords( 'root', 'theme', { status: 'active' } )`
   to pull the user-global-styles id out of the active theme's _links.
   Without (1), that inner getEntityRecords resolver was firing
   independently and producing a network request to /wp/v2/themes.
   PHP knows the id directly, so we now short-circuit the whole chain
   with a synthetic spec that bypasses REST (`{ data: $id }` instead
   of `{ path, method }`).

Test asserts that no /wp/v2/themes request fires during editor mount.

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

Since the legacy preload path list is now wiped entirely (we don't
strip specific keys anymore), the per-spec path-key collection is
unused. Removing it also fixes the "Undefined array key 'path'"
warnings that the new REST-bypass spec shape triggered.

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

Hoists the field list into an exported ROOT_BASE_FIELDS constant on
entities.js, and mirrors it PHP-side in gutenberg_resolve_preload_spec
for getEntityRecord('root', '__unstableBase'). Adds four extra fields
(image_output_formats + the three *_interlaced ones) so the editor
gets image-output-format data alongside the existing site-level
properties.

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

Adds:
- getDefaultTemplateId( { slug } ) → /wp/v2/templates/lookup?slug=…

Slug formula mirrors @wordpress/core-data's private getDefaultTemplate
selector (page / single-{type} / single-{type}-{post_name}).

The JS-side synthesizer dispatches receiveDefaultTemplateId + the
matching receiveEntityRecords for the template, and the main loop fans
out the resolution so that `getEntityRecord('postType', template.type,
id)` is also marked finished — both mirroring what the resolver does
on success.

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

Three specs now share the /wp/v2/settings endpoint: getEntitiesConfig('root')
(OPTIONS, schema), getEntityRecord('root', 'site') (GET, settings), and
the new canUser('read', { kind: 'root', name: 'site' }) (OPTIONS, allow).
rest_preload_api_request still dedupes by URL, so each method runs once
internally — the bucketed $by_key now emits one hydration entry per spec
from the shared response.

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

Entity records have shorthand selectors (`getPostType( 'post' )` for
`getEntityRecord( 'root', 'postType', 'post' )`, etc.). They share the
resolver implementation but each is registered as its own selector with
its own resolution metadata — so the hydration of `getEntityRecord(...)`
alone wasn't preventing callers of the shorthand alias from triggering
their resolver, which in turn refetched the same URL.

Hydrating `getEntityRecord` / `getEntityRecords` now also marks the
matching shorthand selector resolved via `getMethodName(kind, name)`.

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