I dont think it is possible to fix this situation. Rack APIs make heavy use of libraries for which the ABI is not the most stable… Recently it was the case of libzstd version mismatch, that was worked around by hiding those symbols and not allowing plugins to use them.
But this kinda thing will keep happening, there is no way around it… plugins typically are meant to have a single entry point which gives a struct or class and expands from there. Rack uses libcurl, libsamplerate, libarchive, libspeexdsp, osdialog… (I mean, it is quite a few libs) which end up being part of what is considered a public API/SDK. These same libraries also exist as system ones on Linux systems, we are bound to have conflicts when the Rack builds vs distro builds mismatch. It happens more often on ArchLinux because as rolling release it updates more often and it is first in line to catch these issues.
The way to go is as you mention, if using a Rack build from AUR then the plugins should also all be from AUR. In my opinion the AUR build should disable online access, it is by chance if binaries from VCV work or not in this case.