Block Editor: Use default layout type when block specifies unknown va…

…lue.

While working on #38923 with invalid blocks it happened that a JavaScript
error surfaced when working with a block that specified an incorrect layout
type. In the case at hand the block asked for the `flerx` alignment instead
of the `flex` alignment.

It's reasonable to expect blocks to call for unrecognized layouts,
especially if a plugin introduces new layouts and then blocks are loaded
without that plugin's support.

When `getLayoutType` is unable to find a recognized layout it returns
`undefined` which causes numerous issues with calling code that expects
a valid layout.

In this patch we're guarding for those cases and if no known layout can
be found for the specified layout type then we return the default layout
instead. This introduces data corruption so it could be that this solution
is more of a coverup than a fix. There is no way however to ignore that
layout and preserve the behavior while still editing the block. On the
other hand a block should not fail validation due to an implementation bug
in the core editor and if this fix truly resolves the issue we should find
invalidated blocks and prevent editing anyway (unfortunately this is not
the case in this patch).

packages/block-editor/src/layouts/index.js

@@ -13,7 +13,10 @@ const layoutTypes = [ flow, flex ];
  * @return {Object} Layout type.
  */
 export function getLayoutType( name = 'default' ) {
-	return layoutTypes.find( ( layoutType ) => layoutType.name === name );
+	return (
+		layoutTypes.find( ( layoutType ) => layoutType.name === name ) ??
+		layoutTypes.find( ( layoutType ) => layoutType.name === 'default' )
+	);
 }
 
 /**