So it seems that an arm executable cannot host plugins of a different architecture:
Update Plug-Ins to Universal Binaries A universal plug-in runs natively on any Mac computer. If your app supports a plug-in model, create universal versions of the plug-ins that you manage. If your company allows external developers to contribute plug-ins, encourage those developers to create universal versions of their plug-ins. Universal plug-ins are essential if your app loads those plug-ins directly into its process space. Code running in the same process must support the same architecture. If your app attempts to load a plug-in with an incompatible architecture, the system reports an error at load time.
This is not quite true as from testing here you can load Intel AUs into an Arm executable, VST2 and VST3 throw up problems though as the correct architecture cannot be found.
You can see this by doing a build of AudioPluginHost on a M1 machine and running it as Rosseta, scan your plugins and instantiate some, all is fine.
Now Run the Arm version, AUs will load but VSTs will not.
Apples advice here seems to be to host the plugins in an XPC server or the same architecture and communicate with that.
Has any thought been put into all this yet by the June team?