Fix buffer overrun in Paint_Clear() at Scale 65

[timmg]

Paint_Clear() writes 2 * width bytes past the end of the caller's buffer whenever Paint_SetScale(65) is in use — on every call, at every width and height.

Paint_SetScale() sets Paint.WidthByte = Paint.WidthMemory*2 for scale 65, so it holds a byte count (640 for a 320px panel). The inner loop of Paint_Clear() used it as a pixel count, and the body then multiplies by 2 again to form the byte offset. Each row therefore writes 1280 bytes on a 640-byte stride, and the last row runs off the end:

last index written = 2WH + 2W - 1
last valid index = 2WH - 1
overrun = 2W bytes

This changes the bound to Paint.WidthMemory, which counts pixels — matching what the loop body expects. One line.

Verification

A standalone reproduction (no SDK needed, code in the linked issue) reports, before the change:

 320 x 172 buffer 110080 bytes wrote 640 bytes past the end (2*width = 640)
240 x 240 buffer 115200 bytes wrote 480 bytes past the end (2*width = 480)
320 x 240 buffer 153600 bytes wrote 640 bytes past the end (2*width = 640)
128 x 128 buffer 32768 bytes wrote 256 bytes past the end (2*width = 256)
64 x 32 buffer 4096 bytes wrote 128 bytes past the end (2*width = 128)

and with an exactly-sized buffer under AddressSanitizer:

AddressSanitizer: heap-buffer-overflow
WRITE of size 1 ... located 0 bytes after 110080-byte region

After the change: 0 bytes past the end at every size, ASan clean, and the visible buffer is still covered exactly — verified 0 of 110080 bytes left unwritten, no gaps and no change to the rendered result.

Impact

Waveshare's own examples malloc() the framebuffer, so the overrun usually lands in heap slack and produces nothing visible. It becomes serious when the framebuffer is a static array. On an RP2350 board the linker placed TinyUSB's hw_endpoints[] directly after ours, so every redraw destroyed EP0: the board asserted its D+ pull-up but could never answer a SETUP packet, and never appeared on the USB bus at all.

🤖 Generated with Claude Code

Fixes#16 — that issue has the full write-up and a standalone reproduction.