ZoomIt overrides Windows lock/screensaver timeout after unlock or logon

When ZoomIt is running, Windows lock behavior changes after unlocking or logging back in from the lock screen. The system then locks again after about 5 minutes, ignoring the user’s configured lock/screensaver timeout. This does not happen when ZoomIt is not running.

## Observed behavior
1. Start ZoomIt.
2. Lock the workstation.
3. Unlock or log back in.
4. After unlock, Windows begins using an effective 5-minute lock/screensaver timeout instead of the user’s configured setting.
5. Exit ZoomIt and the problem stops.

## Important detail
The settings do not change at lock time. They change only after returning from the lock screen, which suggests the problem is in ZoomIt’s post-unlock/post-logon handling.

## Expected behavior
ZoomIt should not modify or re-apply the user’s global lock screen, secure screensaver, or screensaver timeout settings during normal startup, unlock, or logon handling unless the user explicitly invoked the Break feature that requires temporary screensaver replacement. Any temporary changes should be restored exactly and should never leave behind a different global timeout.

## Likely root cause
The strongest match is in the ZoomIt session-change handler in src/modules/ZoomIt/ZoomIt/Zoomit.cpp. ZoomIt handles WM_WTSSESSION_CHANGE and reacts to WTS_SESSION_UNLOCK, WTS_SESSION_LOGON, and WTS_CONSOLE_CONNECT. That handler schedules SetTimer(hWnd, 5, 5000, NULL), so the actual mutation happens about 5 seconds after unlock/logon.

The timer-5 handler then re-reads ScreenSaveActive and ScreenSaveTimeOut from HKCU\Control Panel\Desktop and calls SPI_SETSCREENSAVEACTIVE and SPI_SETSCREENSAVETIMEOUT. The suspicious fallback is a hardcoded timeout of 300 seconds if the registry read fails or the value is missing, which matches the observed 5-minute relock behavior.

## Suggested fix
1. Do not call SPI_SETSCREENSAVETIMEOUT or SPI_SETSCREENSAVEACTIVE on unlock/logon unless ZoomIt previously entered the break-screensaver flow and is restoring its own temporary override state.
2. Remove the hardcoded 300-second fallback. If ZoomIt cannot determine the user’s current timeout, it should do nothing instead of imposing a new global timeout.
3. Gate the post-unlock timer path on explicit break-mode state, such as an active or orphaned ZoomIt break screensaver override.
4. Restore only exact previously captured values and do not synthesize replacement global lock/screensaver policy values.

Start in src/modules/ZoomIt/ZoomIt/Zoomit.cpp by tracing the WM_WTSSESSION_CHANGE handling for WTS_SESSION_UNLOCK, WTS_SESSION_LOGON, and WTS_CONSOLE_CONNECT, then follow timer 5. Check how ScreenSaveActive and ScreenSaveTimeOut are read and restored. Done means unlock or logon does not alter global screensaver settings unless an explicit Break override is active, and missing registry values do not produce a 300-second fallback.

Written by the indexing model from the issue text.