tests: load plugin into default AssemblyLoadContext for MVC controller discovery

Real fix for master CI #22 failure (and likely the original race on
PR #12 we worked around with HTTP-only testing).

Root cause: BTCPay defaults plugin loading to an isolated
AssemblyLoadContext so production plugins can be swapped without
restarting the server. In the test process, the isolated context
makes the plugin's assembly invisible to MVC ApplicationParts
discovery - so the plugin's IBTCPayServerPlugin instance shows up
in the DI list but POSTs to its controller routes 404.

The retry-with-backoff in the previous commit didn't help because
the route never registers, not because it lags. Removing the retry
loop now that the real fix is in.

Mirror of rockstardev/btcPayServerPlugins.RockstarDev's
SharedPluginTestFixture which sets LoadPluginsInDefaultAssemblyContext
= false before ServerTester.StartAsync().

Author: r1ckstardev

SamRockProtocol.Tests/SharedPluginTestFixture.cs

@@ -37,6 +37,15 @@ public void Initialize(UnitTestBase testInstance)
 
             var testDir = Path.Combine(Directory.GetCurrentDirectory(), _testDirName);
             ServerTester = testInstance.CreateServerTester(testDir, _useNewDb);
+            // BTCPay defaults plugins to isolated AssemblyLoadContext so production
+            // plugins can be unloaded/swapped without restarting. In tests the
+            // isolated context makes the plugin's assembly invisible to the test
+            // process's MVC ApplicationParts discovery, so the controllers never
+            // route (the plugin shows in DI but POSTs to its endpoints 404).
+            // Load into the default context so MVC can discover the controllers.
+            // Mirrors rockstardev/btcPayServerPlugins.RockstarDev's test fixture
+            // and closes the master CI #22 OTP-404 failure deterministically.
+            ServerTester.PayTester.LoadPluginsInDefaultAssemblyContext = false;
             ServerTester.StartAsync().GetAwaiter().GetResult();
         }
     }