win: don't make the center view native when reading the display profile

[radialmonster]

Fixes #20442.
Fixes #21484.
Fixes #21829.
Fixes #22265.

dt_colorspaces_set_display_profile() called gdk_win32_window_get_handle() on the center widget's GdkWindow. For a client-side window, GDK calls gdk_window_ensure_native() there, so the first profile read turned the center view into a native child HWND for the rest of the session. GtkOverlay re-shows its child windows on every size allocation, which raises them (gtkoverlay.c: "gdk_window_show() does an implicit raise"). GDK's Win32 raise calls SetForegroundWindow() on a native window. So any re-layout in the center (thumbnail hover overlays, thumbnails loading, toasts, log messages) pulled darktable in front of other applications, even while it was minimized.

This is a regression from #20054; before it, the Windows branch used GetDC(NULL).

The HWND is only used to find the monitor, so this takes it from the toplevel, which is native already. DT_COLORSPACE_DISPLAY2 passes the second window, which is itself a toplevel, so that path is unchanged.

Testing (Windows 11 25H2, two monitors): an automated probe opens Notepad from the Start menu and moves the pointer once onto a thumbnail. Notepad lost the foreground in 25/27 trials on master and 0/21 with this change (5.6.1: 18/18 vs 0/14). With the pointer parked on the other monitor, a log message expiring stole the foreground 5/5 times without the change and 0/4 with it. The display profile still switches when the window is moved to the other monitor.

#21484 is the same bug seen through Alt+Tab: with the pointer on a thumbnail, Alt+Tab failed in 6 of 8 launches without this change and 0 of 7 with it.

#21829 is the same cause reached through export progress messages. A 225-image export with another window in front: 15 and 2 steals in two runs without this change, 0 in two runs with it, and the progress messages stay visible. Its cross-desktop symptom behaves the same way: with an app open on a second virtual desktop, an unfixed build pulled the desktop back after about 30 images in both runs, and stayed put in both runs with this change. Note that console pop-ups (#17193) are a second, unrelated source of focus loss during exports, so if anyone still sees it with this change, that issue should be reopened and looked at there.

This is unrelated to the console pop-ups addressed by #22070 / #17193; a launcher-started build still reproduces 8/8.

AI Assisted with this issue

[radialmonster]

@Dannny1 since this changes the code from #20054, could you check that per-monitor color management still works for you with it? Here the display profile still switches when the window is moved between two monitors with different profiles, but your setup may differ.

Related: #21949. The two fit together — this removes the cause, so #21949 can keep its background-jobs GTK-thread fix without needing the Windows message suppression, and Windows keeps the export and import progress messages.

[Thanatomanic]

I have tested this change on my Windows machine, self-compiled on both the darktable-5.6.x and master branches. No focus stealing on import, export, or hover over thumbnails due to window refreshes or draws.

I cannot judge whether the color management on a secondary display is still working, because I don't understand the initial problem 🙃