Fix #19390: Make snap-on-input conditional to prevent blocking programmatic scroll (#19414)

## Summary of the Pull Request
This PR fixes a bug where programmatic scrolling would get stuck. The
fix makes the "snap-on-input" feature conditional, activating it only
for modern applications that use Virtual Terminal (VT) processing. This
restores correct scrolling behavior for legacy applications without
removing the feature for new ones.

## References and Relevant Issues
Fixes #19390: OpenConsole: Cursor visibility prevents programmatic
scrolling

## Detailed Description of the Pull Request / Additional comments
The "snap-on-input" feature introduced in a previous PR caused an
unintended side effect for older console programs that use the
SetConsoleWindowInfo API to manage their own viewport. When such a
program tried to scroll using a key press, the snap feature would
immediately pull the view back to the cursor's position, causing the
screen to flicker and get stuck.

This fix makes the snap-on-input feature smarter by checking the
application's mode first.

## Validation Steps Performed

Compiled the minimal C++ reproduction case from issue #19390.

Ran the test executable inside the newly built OpenConsole.exe.

Confirmed that scrolling with the Up/Down arrow keys now works
correctly, even with a visible cursor. The view no longer flickers or
gets stuck when the cursor moves outside the viewport.

Closes #19390

Author: vididvidid

src/host/input.cpp

@@ -170,7 +170,12 @@ void HandleGenericKeyEvent(INPUT_RECORD event, const bool generateBreak)
 
         if (gci.HasActiveOutputBuffer())
         {
-            gci.GetActiveOutputBuffer().SnapOnInput(keyEvent.wVirtualKeyCode);
+            auto& buffer = gci.GetActiveOutputBuffer();
+
+            if (WI_IsFlagSet(buffer.OutputMode, ENABLE_VIRTUAL_TERMINAL_PROCESSING))
+            {
+                buffer.SnapOnInput(keyEvent.wVirtualKeyCode);
+            }
         }
     }
 }