Windows: restore main window after Pick location (fixes #3)

[Quadstronaut]

Summary

• Fixes Windows: Pick location loses main window — coordinates captured but app appears to vanish #3 — clicking Pick… captured coordinates but left the main window hidden, so the app appeared to vanish.
• BeginPick minimizes the owner so the target is visible; Window_StateChanged turns that into Hide(). The pick callbacks only restored WindowState, which does not undo Hide() in WPF.
• Adds Show() to OnLocationPicked and OnPickCancelled, matching the existing RestoreFromTray pattern.

Test plan

• dotnet build windows/QuadClicker.csproj -c Release — clean
• Manual: select Fixed XY, click Pick…, click target → main window returns with X/Y populated
• Manual: select Fixed XY, click Pick…, press ESC → main window returns unchanged
• Manual: minimize-to-tray (close button / minimize) still hides as before

🤖 Generated with Claude Code

[Quadstronaut]

Pushed c10a9e8 — diagnosed wrong root cause initially.

What the previous fix actually addressed: restoring the main window after OnLocationPicked runs. That code path was never being entered because the click was never captured in the first place — the overlay just sat there.

Real root cause (likely): LocationPicker.SetHook passed GetModuleHandle(Process.MainModule.ModuleName) for hMod. On .NET 10 apphost / single-file deployments the loaded EXE module can register under a name that doesn't match MainModule.ModuleName, so that lookup silently returns 0. SetWindowsHookEx then returns IntPtr.Zero and the hook is never installed. The overlay shows, the user clicks, nothing happens.

Fix: pass GetModuleHandle(null) — Win32-documented form that always returns the EXE's HMODULE.

Also added file-based diagnostics at %APPDATA%\QuadClicker\picker.log covering each stage of the pick (BeginPick → ShowOverlay → SetHook result + GetLastError → HookCallback fired → dispatcher action ran). Plus the overlay now turns its hint label red and points at the log file if SetHook returns 0, so future regressions are debuggable on a user's machine without attaching a debugger.

Test plan extension:

• If picker still doesn't capture clicks, attach %APPDATA%\QuadClicker\picker.log

[Quadstronaut]

Pushed ae79f48. The diagnostic log from the previous build pointed at the actual root cause within one repro:

[2026-04-26 00:10:09.687] BeginPick: exception EntryPointNotFoundException:
Unable to find an entry point named 'GetModuleHandle' in DLL 'kernel32.dll'.

kernel32 only exports GetModuleHandleA / GetModuleHandleW. The classic [DllImport(CharSet=Auto)] style auto-appended W; the newer [LibraryImport] source generator does not — even with StringMarshalling.Utf16 you must set EntryPoint explicitly. So every call to NativeMethods.GetModuleHandle was throwing. The overlay was already shown by the time SetHook blew up, which is why the picker just sat there with no obvious failure.

Fix: drop the GetModuleHandle P/Invoke and use Marshal.GetHINSTANCE(typeof(LocationPicker).Module) for hMod. WH_MOUSE_LL hooks run in the calling thread regardless of hMod, so any valid module handle works.

Diagnostics stay — they paid for themselves immediately and will catch the next regression in this area without another guess-and-build cycle.