Fix Gutenberg_REST_View_Config_Controller_7_1 PHP warnings

[ntsekouras]

What?

Follow up of: #76734

• Fix PHP warning Undefined array key "layout" when requesting view config for
  wp_template_part — get_default_layouts_for_wp_template_part() was missing the layout key
  in its grid entry
• Add defensive ?? array() fallback at all $default_layouts access sites to prevent
  similar issues in the future

Testing Instructions

1. Verify templates parts page in site editor (through patterns menu item) works as before
2. No PHP warnings

Use of AI Tools

Opus 4.6

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[oandregal]

This should fix it, thanks. Are the other changes necessary given the data will be always defined?

[oandregal]

Add defensive ?? array() fallback at all $default_layouts access sites to prevent similar issues in the future

They won't prevent the issue in the future, as the issue was trying to access an undefined key (layout)?

[ntsekouras]

Not really. It's defensive programming as I wasn't sure if they will be always defined. Is that the case? If yes, I can remove them.

[ntsekouras]

They won't prevent the issue in the future, as the issue was trying to access an undefined key (layout)?

It seems they would due to the warning suppression of ?? operator. That said, I'll remove them for now and only keep the layout fix.

[mcsf]

It seems they would due to the warning suppression of ?? operator

Correct, they would.

I recommend still thinking about failure modes in this endpoint. Since $default_layouts is a dynamic value and not some pseudo-constant that we can easily verify, and since we don't have any meaningful static typechecking, it seems like these warnings can easily pop up again. And this will be all the more important once filters enter the scene.

[github-actions]

Flaky tests detected in 569c5f9.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24388852316
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should insert two subsequent mentions #71871 in /test/e2e/specs/editor/various/mentions.spec.js
• [Flaky Test] should show correct homepage actions based on current homepage or posts page #68892 in /test/e2e/specs/site-editor/homepage-settings.spec.js

[oandregal]

Can you backport this to the corresponding core PR?