Fix a OOB write in SixelParser

[lhecker]

The SixelParser state machine assumes that _resizeImageBuffer
succeeded. The state that determines the X/Y size of the buffer
is set outside of the resize function.
This meant that an OOM failure can cause the resize to fail
and the buffer X/Y size variables to be out-of-sync.
A later write in the buffer will then be out of bounds.
Whether that's before or after the buffer address depends
on whether the 32-bit coord multiplication overflows or not.

Closes #20149

Validation Steps Performed

• Run the repro (super tall sixel), specifically
  in PowerShell 5 (depends on its particular chunking)
• OpenConsole.exe doesn't crash

[j4james]

Would it not be simpler to catch the out of memory exception in the handler here, and then return false?

terminal/src/terminal/adapter/SixelParser.cpp

Lines 92 to 95 in eeb9f7a

	return [&](const auto ch) {
	_parseCommandChar(ch);
	return true;
	};

I believe that should tell the state machine to ignore all further content in the sequence, so there should be no chance of the buffer being used after that.

And while dealing with the OOM exception is a good thing either way, I'd prefer it if you also implemented the patch I posted in #20149 (comment), because this particular case should never have used that much memory in the first place - that's the real bug that #20149 identified. If you don't want to address that in this PR, at least leave the issue open.

[lhecker]

Would it not be simpler to catch the out of memory exception in the handler here, and then return false?

omg I completely forgot about this behavior of our parser! I wonder why this didn't occur to me...

And while dealing with the OOM exception is a good thing either way, I'd prefer it if you also implemented the patch I posted [...]

I intended to file a follow-up issue. But given that your suggested fix is a lot tidier than mine, I'll simply piggy-back your proper fix here. Thank you for the feedback!