[AmirHBuilds]

When night mode is enabled and the window is minimized and then restored,
the whole window briefly flashes light/white before the dark UI is painted.
This happens only with Telegram Desktop on Windows (other apps are fine).

The cause is that nothing handles WM_ERASEBKGND for the main window, so
Windows shows a blank frame before Qt repaints the dark theme.

This change handles WM_ERASEBKGND in the main window event filter and fills
the client area with the current window background color, but only when
night mode is active. Light mode behavior is unchanged.

Tested: built a Debug x64 binary via the Windows. workflow on my fork,
minimized and restored the window several times with night mode on.
The flash no longer appears.

[CLAassistant]

All committers have signed the CLA.

[ilya-fedin]

Are you sure it's the right thing to do? AFAIK Qt handles WM_ERASEBKGND to say Windows it shouldn't paint anything. But I also remember that it doesn't actually work for unknown reason and we work around that by using cloaking. So I assume you should re-use the cloaking workaround here or find why Qt's WM_ERASEBKGND handler doesn't work (I assume you use AI and it should be able to do it)?

[AmirHBuilds]

Are you sure it's the right thing to do? AFAIK Qt handles WM_ERASEBKGND to say Windows it shouldn't paint anything. But I also remember that it doesn't actually work for unknown reason and we work around that by using cloaking. So I assume you should re-use the cloaking workaround here or find why Qt's WM_ERASEBKGND handler doesn't work (I assume you use AI and it should be able to do it)?

Thanks for the review. You're right, I wasn't aware of the cloaking
workaround. My handler fixed the flash in my testing, but I didn't
investigate why Qt's own handling doesn't prevent it. I'll look at how
cloaking is used in lib_ui and rework the change to use it. Converting
this PR to draft until then.