iso.blocks.allowBlocks is ignored

Hello!

I would like to report an issue which seems to be present since at least ISO 2.26.0 release. The following ISO settings are ignored when used on a WordPress website:

`iso.blocks.disallowBlocks` and `iso.blocks.allowBlocks`.

These settings were working fine before, but now all WordPress blocks are always allowed, whether these settings are filled or not (same behavior in ISO 2.27.0).

[Blocks Everywhere](https://github.com/Automattic/blocks-everywhere/), which use ISO, added [the following code as a workaround](https://github.com/Automattic/blocks-everywhere/commit/f11232c5a24f5f712bddfe0150b81b7371985132#diff-7ee6c0a2f0093f8c1f315c4be6d17d4ba350b4de2b9634a73d43db4bd67d939eR51) since their 1.20 update (which use ISO 2.26.0):

```js
function RemoveBlockTypes() {
useEffect( () => {
const blocks = getBlockTypes()
.filter( ( block ) => wpBlocksEverywhere.iso.blocks.allowBlocks.indexOf( block.name ) === -1 )
.forEach( ( block ) => {
unregisterBlockType( block.name );
} );
}, [] );

return null;
}

// ...

```

As you can see it now unregister unwanted blocks, which might be fine in their case (single editor instance). But if you have multiple editor instances and use this workaround, it will break other editors that want to use a previously unwanted block.

I didn't see this issue posted here and it seems that Block Everywhere decided to implement this workaround without reporting it. Are you aware of this issue? Is this intended? Do you have any workaround which would not require to unregister block types?

Thanks!

Regards.

Start by reproducing the issue with iso.blocks.allowBlocks and iso.blocks.disallowBlocks in a WordPress editor instance, then trace where those settings are handled. Compare the behavior with the Blocks Everywhere workaround that filters getBlockTypes() and unregisters blocks. Done means each editor instance respects its configured allowed and disallowed blocks without breaking other instances.

Written by the indexing model from the issue text.