Windows C# hosted libbox: memmod-loaded WinTun crashes (runtime.cgocallback / exitsyscall), file-backed loading is stable

We observed a reproducible crash only in C# hosted mode (Go c-shared loaded by .NET), when WinTun is loaded from in-memory loader path (memmod).

Environment:

Windows
C# host (WinUI app process + service process model)
libbox built as Go c-shared
inbound tun enabled
Symptoms:

fatal error: exitsyscall: syscall frame is no longer valid
runtime.cgocallback in stack
sometimes process exit code -1073741819
Key comparison:

inbound tun disabled: stable
inbound tun enabled + memmod WinTun: crash
inbound tun enabled + file-backed WinTun (LoadLibraryEx): stable (10/10 runs)
pure Go test program + memmod: stable
Interpretation:
The issue seems specific to multi-runtime hosted boundary (.NET CLR + Go c-shared + native callback threads), not WinTun function itself.
Using Windows standard loader path (file-backed DLL) avoids the crash in hosted mode.

Proposed direction:

Keep file-backed WinTun as default in C# hosted scenarios
Keep memmod path for experimental/debug only
Consider documenting this constraint for hosted runtimes
Repro hints:

Set LIBBOX_DLL_FORCE_MEMMOD_WINTUN=1 -> crash likely in hosted mode
Set LIBBOX_DLL_USE_FILE_WINTUN=1 -> stable in hosted mode

No source file or test is named. Reproduce the hosted C# case with inbound tun enabled using LIBBOX_DLL_FORCE_MEMMOD_WINTUN=1, then compare it with LIBBOX_DLL_USE_FILE_WINTUN=1 and the pure Go program; done means the hosted path no longer crashes or the file-backed constraint is documented and enforced.