fix(canvas): stop the overlay erasing the frame the GPU canvas painted

[seanharding]

With GPU acceleration on, the canvas showed nothing at all: white on macOS, black on Windows. Linux was unaffected.

CanvasOverlay punched an alpha hole through the whole canvas rect on macOS and Windows whenever the GPU widget was visible. That is correct for a screen present, where a native surface sits behind the Qt widgets and the hole reveals it. rendercanvas deliberately picks a bitmap present on Qt, so the frame is read back and blitted into the same backing store by the canvas's own paintEvent; the overlay paints on top afterwards and wipes it. What remains is the bare window background, which is light on macOS and black on Windows.

The hole is now punched only when there really is a native surface underneath, which GPUCanvasWidget.presents_to_screen() reports from the canvas itself rather than from a platform guess.

The compositing has been wrong since it was written; it only became visible when the soft proof moved into the display LUT. Before that, a proofed render was baked to a host array on the render thread, and soft proofing is on by default, so every default frame took the CPU/QPainter branch of ImageCanvas.update_buffer and the GPU widget was never in the path.

Verified against the real app: compositing the canvas the way the screen does gives a frame that matches the presented bitmap (mean 95.2 / std 98.0 against 1.4 / 11.0 before), and zoom and pan leave no residue — the canvas re-blits under every overlay repaint, which is what clears it now that the fill is gone.

Fixes #781

[dtrtuser]

thanks, works like a charm now. and great performance too!