fix: correct SGR mouse-wheel button codes (64/65/66/67, not 68/69/70/71)

[smohekey]

Problem

TerminalMouseButton encodes the wheel buttons with the wrong values:

wheelUp(id: 64 + 4),    // = 68
wheelDown(id: 64 + 5),  // = 69
wheelLeft(id: 64 + 6),  // = 70
wheelRight(id: 64 + 7), // = 71

In the X10/SGR mouse protocol the four wheel buttons are 64/65/66/67: bit 6 set (the high-button/"wheel" bit, +64) with the button number carried in the low two bits. The enum adds the raw button number (4/5/6/7) on top of 64 instead of transposing it into the low bits, giving 68/69/70/71.

Those extra bits are the modifier bits of the encoding: 68 = 64 + 4 is wheel-up with Shift, 69 is wheel-down with Shift, and so on. So every wheel report the terminal emits carries a spurious Shift modifier.

Impact

Applications that check the button field reject the report as a modified/invalid wheel event and don't scroll. (More lenient apps mask the modifier bit and still scroll, which is why this often goes unnoticed.) On the alternate screen, TerminalScrollGestureHandler forwards wheel events through mouseInput, so a strict full-screen TUI never scrolls from the wheel.

Fix

Encode the wheel buttons as 64 + (0/1/2/3) — bit 6 plus the button number in the low two bits — matching the SGR spec and xterm.

Verified against an app that enables SGR mouse mode (?1006) with any-event tracking (?1003): a wheel-down previously emitted ESC[<69;…M and did nothing; it now emits ESC[<65;…M and the app scrolls. ESC[M (normal-encoding) reports are corrected the same way.