Fix DECSTR cursor restore in alt screen buffer (#19918)

[aarushisingh04]

summary of the pull request

fixes decstr behavior so a soft reset in the alt screen buffer does not clear the saved cursor state for the main screen buffer.

references and relevant issues

• closes DECSTR was incorrectly handled inside the Alternate Screen Buffer #19918

detailed description of the pull request / additional comments

the prior implementation of AdaptDispatch::SoftReset() reset both saved cursor states unconditionally:

• main buffer saved cursor state
• alt buffer saved cursor state

this caused a regression where sending decstr (esc[!p) while in the alt buffer could clear the main buffer cursor restore point, so returning from alt buffer no longer restored the expected cursor position.

this change updates soft reset behavior to clear only the saved cursor state for the currently active buffer, matching expected xterm-compatible behavior and preserving main buffer cursor restore data when resetting in alt mode.

a regression unit test was added to cover this scenario:

• set a known cursor position in main buffer
• enter alt buffer
• send decstr
• leave alt buffer
• verify cursor restores to the original main buffer position

validation steps performed

• built unit test target containing Conhost.Unit.Tests.dll
• ran targeted taef tests:

packages\Microsoft.Taef.10.100.251104001\build\Binaries\x64\TE.exe bin\x64\Debug\Conhost.Unit.Tests.dll /name:*VtSoftResetAltBufferCursorState* /unicodeoutput:false
packages\Microsoft.Taef.10.100.251104001\build\Binaries\x64\TE.exe bin\x64\Debug\Conhost.Unit.Tests.dll /name:*VtSoftResetCursorPosition* /unicodeoutput:false
packages\Microsoft.Taef.10.100.251104001\build\Binaries\x64\TE.exe bin\x64\Debug\Conhost.Unit.Tests.dll /name:*TestAltBufferCursorState* /unicodeoutput:false

[DHowett]

this type of diff which changes the line endings of entire files is, unfortunately, unacceptable. Please use a text editor that will respect the existing line endings in this repo.

[aarushisingh04]

@DHowett apologies, it has been addressed