Repeated post-type schema requests in the Site Editor #564

With SCF active, the Site Editor can repeatedly request the same post-type
schema as blocks mount. This affects both the Templates overview with previews
enabled and individual archive templates containing a Query Loop. Larger block
counts increase the duplicate work even when the number of post types is unchanged.

In practice this issue has been leading to dozens of API requests on a production
site during FSE use, bringing a 4-core VPS to it's knees affecting site visitor
experience negatively.

Synthetic benchmark linked below have been made with similar CPT and block counts as used on
the affected site using FSE theme to simulate the impact.

Reproduced on WordPress 7.1.2 / SCF 6.9.4 and WordPress 7.1.3 / SCF 6.9.6.

Steps to reproduce

1. Activate SCF and a block theme, with a registered, REST-visible custom post type.
2. Add an archive template for that type containing a populated Query Loop.
3. Open the archive in the visual Site Editor, or enable template previews in
   the Templates overview.
4. Inspect calls to /wp/v2/types/{type}?context=edit as blocks mount.
5. Increase the number of rendered blocks without adding post types and compare
   the repeated schema lookups. Disabling overview previews removes that source
   of block mounts and duplicate work.

The duplicate requests occur for valid, registered types; missing-type/404
responses are a separate case.

Expected behavior

Concurrent consumers should share the post-type schema resolution, rather than
fetch it independently for each block. Edit-context field definitions must remain
available to bindings, with normal permission checks and deliberate retry/refresh.

Likely cause and proposed fix

useSiteEditorFields performs per-instance apiFetch work. Block mounts therefore
produce duplicate lookups for the same schema.

Use core-data's native getPostType(type) selector/resolver consistently for
selection, loading/error state and invalidation. On the tested cores, its default
context is edit, preserving SCF field definitions without a module-global cache.

The exact selector identity matters: generic getEntityRecord lookups and the
native getPostType alias can resolve independently even when they request the
same URL. Sharing only among SCF consumers can still duplicate the native editor's
request.

Optional inspector gating can be reviewed separately. The shared resolver fix
alone removed the observed fan-out; gating did not further reduce schema counts
in the matched representative cases.

Validation summary

A separate synthetic reproduction repository contains the fixtures, runnable
instructions, candidate patches and detailed evidence.

https://github.com/jasalt/scf-fanout-issue-lab

Main findings:

• With six post types fixed, increasing mounted preview blocks from 320 to 536
  increased unpatched schema calls from 648 to 1080; the candidate stayed at
  8 in both cases.
• In an archive editor, target-type edit-schema calls fell from 151 to 1,
  including the native editor's lookup.
• A minimal single-type fixture also reproduced the issue. Block mounts and
  collection-request counts remained unchanged across the matched builds.
• The selected comparisons used three fresh browser contexts per condition,
  with cold and warm documents reported separately. Binding, field-availability,
  permission/context and resolver-lifecycle checks are documented in that repository.

Counts refer to apiFetch invocations, which may use preloaded responses—not
necessarily separate HTTP executions. These findings demonstrate duplicate-work
removal, not a production speedup or an exhaustive compatibility matrix.

Requested review

Please review sharing the native post-type resolver as the primary fix, including
edit-field availability and retry/refresh invalidation. Inspector gating can remain
a separate change. The proposed changes were AI-assisted (PiG harness & gpt-6.1-sol model)
and require human review and applicable CI before merge.