I continued to hammer away at this and it seems that the dynamic load has nothing to do with the problem. I wouldn't put money on that claim because I could swear I could control failures by twiddling references in Visual Studio - but after more testing, it seems that it's entirely an issue of assembly attributes.
There were two (of four) assembly attributes that needed to be removed if the profiler was going to run.
[assembly: PermissionSet(SecurityAction.RequestOptional, Name = "Nothing")]
[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted = true)]
Once removed, the process ran normally while being profiled.
SecurityAction.RequestOptional is listed as being obsolete, but there are two other assembly attributes in the same DLLs that use obsolete SecurityActions that do not block the profiler:
[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
[assembly: SecurityPermission(SecurityAction.RequestRefuse, UnmanagedCode = true)]
I haven't tried twiddling with this stuff because I don't have a clue what it does.