fix: clamp negative mouse coordinates to prevent @intCast panic

[sakakibara]

Mouse coordinates can be negative when cursor moves off-screen during rapid movement. Since vxfw.Point uses u16, the @intCast panics on negative i16 values.

[LordAizen1]

Sorry for poking at an old PR. I know main has moved a lot since December so this would need a rebase, but the thing it fixes is still there on current main, so it felt worth flagging.

Nice catch on the panic, this one is real. @intCast on a negative does abort with "integer does not fit in destination type", and the parser genuinely produces negative coordinates, there's even a test for it (parse(csi): mouse (negative) expects col = -51).

One thing I'd raise about clamping to 0 though. The root SubSurface in updateMouse has its origin hardcoded to (0, 0), and Point is unsigned, so containsPoint reduces to just the upper bound checks:

point.col >= self.origin.col   // u16 >= 0, always true

So a mouse at col = -5 clamps to col = 0, reports as inside the surface, and the top-left widget gets the event. It ends up asymmetric:

off-screen left  (col -5 -> 0):  containsPoint = true
off-screen right (col 200):      containsPoint = false

Would skipping the hit test entirely for negative coordinates work instead? Something like leaving hits empty when mouse.row < 0 or mouse.col < 0, so the existing enter/leave diffing sends mouse_leave to whatever was hit last frame. That feels closer to "the mouse is off screen, nothing is hit" than snapping to the corner. Could easily be missing context on why clamping is preferred here though, no rush from me either way.