Pin the host module instead of wrapping a borrowed HMODULE

[JustinMDotNet]

Closes #142.

What this changes

PluginSystem::Load now acquires a real owning reference for the host executable path instead of wrapping the borrowed handle from GetModuleHandleA(nullptr):

HMODULE raw = nullptr;
if (GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_PIN, nullptr, &raw))
{
    handle.reset(raw);
}

GET_MODULE_HANDLE_EX_FLAG_PIN pins the host module for the life of the process. Per the docs, subsequent FreeLibrary calls on a pinned module are a no-op, so the eventual wil::unique_hmodule destructor (here or in PluginBase) is harmless and the loader refcount stays balanced.

Why

The previous code stored the result of GetModuleHandle directly in wil::unique_hmodule. Microsoft's GetModuleHandle docs say:

The GetModuleHandle function does not increment a module's reference count, so this handle should not be passed to the FreeLibrary function.

wil::unique_hmodule calls FreeLibrary on destruction, so the borrowed handle was being passed to FreeLibrary in two paths:

1. When the host .exe did not export Supports, the local handle went out of scope at the end of Load — FreeLibrary was called on the process image.
2. When the host .exe was accepted as a plugin, PluginBase::m_module (also a wil::unique_hmodule, see PluginBase.hpp:38) would do the same on unload.

Both paths fire on every startup because of the unconditional Load(m_paths.GetExe(), false) self-probe in PluginSystem.cpp:172. Windows happens to be forgiving about the process image specifically, which is why this has been invisible, but it is still a real Win32 contract violation.

Design choice

Two reasonable alternatives, both rejected for being more invasive:

• Tagged union / separate non-owning HMODULE. Cleanest, but requires changing PluginBase's member layout and every site that touches it.
• std::optional<wil::unique_hmodule>. Same problem at the PluginBase boundary.

Pinning is a one-line change that keeps the existing RAII model intact and is exactly what GET_MODULE_HANDLE_EX_FLAG_PIN was designed for. The host executable can never be unloaded anyway, so pinning costs nothing.

If GetModuleHandleExW fails for any reason, handle stays empty and the existing if (!handle) check at PluginSystem.cpp:242 reports it as a load failure, same as before.

What I tested

Local rebuild. Behavior change in the common case is just that the loader refcount stays correct.