Part of #76544
Follows-up on #76573 (comment)

What?

Extracts the per-entity view configuration logic out of Gutenberg_REST_View_Config_Controller_7_1 into a standalone, filterable API.

No change to the REST response shape (default_view, default_layouts, view_list, form).

Why?

Previously, the view configuration for every entity was hardcoded inside the REST controller and was not filterable.

Moving the logic behind a dynamic filter:

• Makes the view config extensible per kind/name (e.g. custom post types, custom entity kinds).
• Decouples the data model from the REST transport, so the same config can be reused outside the endpoint.
• Keeps the controller focused on REST concerns (schema, permissions, serialization).

How?

• New file lib/compat/wordpress-7.1/view-config-api.php with a public gutenberg_get_entity_view_config( $kind, $name ) function.
• The function builds the default config shared by all entities, then exposes it through a dynamic get_entity_view_config_{$kind}_{$name} filter so core and third parties can provide entity-specific configuration.
• The existing per-entity configs (postType × page, post, wp_block, wp_template_part, wp_template) are moved out of private controller methods and re-registered as filter callbacks.
• The REST controller (/wp/v2/view-config) now keeps only the routing, permission, and schema plumbing and delegates data building to gutenberg_get_entity_view_config().

Testing Instructions

These screens are powered by the /wp/v2/view-config endpoint via getViewConfig / useViewConfig (@wordpress/views). Confirm the refactor produces identical behavior.

1. Build Gutenberg (npm run build or npm run dev) and activate the plugin.
2. Open the Site Editor and verify each DataViews screen renders with its expected columns, default layout, and saved-view list (these come from default_view, default_layouts, view_list):
   • Pages — list layout with hierarchy levels, featured-media field, and the view list (All, Published, Drafts, Scheduled, Trash, etc.).
   • Posts — list with the post DataForm fields in the sidebar.
   • Patterns (wp_block) — grid layout and its view list.
   • Template Parts — its layout and view list.
   • Templates — table layout and the author-based view list (verify author filters appear).
3. Open a Page and a Post in the editor and confirm the post summary / DataForm sidebar fields render correctly (form config: featured image, excerpt, status/scheduled date/password/sticky, slug, author, template, discussion, parent, format).
4. Hit the endpoint directly and confirm the response is unchanged from trunk for each entity:
   • wp.apiFetch( { path: '/wp/v2/view-config?kind=postType&name=page' } ).then( console.log ) — repeat for post, wp_block, wp_template, wp_template_part.
   • Compare the JSON against trunk — default_view, default_layouts, view_list, and form should be byte-for-byte equivalent.
5. Verify the new extensibility point works — temporarily add a filter and confirm it's applied:

   add_filter( 'get_entity_view_config_postType_page', function ( $config, $entity ) {
       $config['default_view']['perPage'] = 5;
       return $config;
   }, 20, 2 );

   Reload the Pages screen / re-fetch the endpoint and confirm perPage is now 5.
6. Confirm a kind/name with no registered filter (e.g. kind=postType&name=attachment) still returns the generic default config without errors.
7. Confirm the permission gate is intact: an unauthenticated request (or a user without edit_posts) returns rest_cannot_read / 401.

Use of AI Tools

This pull request was prepared with the assistance of AI tooling (Claude Code). All changes were reviewed by the author, who takes responsibility for them.