CoreTests: use_interface_from_interop_message_naming is order-dependent and fails on main

[jeremydmiller]

CoreTests.Util.WolverineMessageNamingTests.use_interface_from_interop_message_naming fails when the full CoreTests suite runs.

This is pre-existing on main, not related to the xUnit v3 migration. Verified three ways, all producing an identical 2104 total / 2101 passed / 1 failed / 2 skipped:

Tree	Result
pristine origin/main (bd019dbba, xUnit 2, runner 2.8.2)	1 failed
xUnit v3 migration wave 0 (xUnit 2, runner 3.1.5)	1 failed
xUnit v3 migration wave 2 (xUnit v3)	1 failed

Failure

Shouldly.ShouldAssertException : typeof(ConcreteMessage).ToMessageTypeName()
    should be "Module1.IInterfaceMessage" but was "CoreTests.Util.ConcreteMessage"

Cause

WolverineMessageNaming.ToMessageTypeName memoises into a static ImHashMap cache (src/Wolverine/Util/WolverineMessageNaming.cs:140), and WolverineRuntime.HostService.StartAsync pre-populates it via PrepopulateCache(Handlers.AllMessageTypes()) (WolverineRuntime.HostService.cs:132).

The test calls AddMessageInterfaceAssembly(...) and then expects ConcreteMessage to resolve through its interface. But CoreTests boots hundreds of Wolverine hosts, and any of them that discovers CoreTests.Util.ConcreteMessage as a message type caches it under its plain name first. The later AddMessageInterfaceAssembly call cannot displace the cached entry.

So whether the test passes depends purely on execution order, and it also leaks global state in the other direction — once it runs, interface naming is registered for every subsequent test in the process.

Options

• Give the test a message type that nothing else can discover (though assembly scanning makes this fragile).
• Add an internal reset/eviction hook on WolverineMessageNaming for tests.
• Register the interface assembly once at assembly-fixture level so ordering cannot matter.

Passes in isolation, which is why it has survived unnoticed.