Fix captureScreen hang when server responds with only pseudo-encodings

[HZNAN]

Problem

captureScreen (and the CLI capture command) hangs indefinitely when the VNC server responds to a FramebufferUpdateRequest with only pseudo-encoding rectangles and no actual pixel data.
This has been reported in #267 and affects multiple VNC servers including TigerVNC and WayVNC.

Reproduction

$ vncdo -s ::5900 -p capture screenshot.png

Debug log shows the server returns only pseudo-encodings:
DEBUG:vncdotool.client:captureScreen screenshot.png INFO:twisted:x=0 y=0 w=0 h=0 <Encoding.PSEUDO_QEMU_EXTENDED_KEY_EVENT: -258> INFO:twisted:x=0 y=0 w=0 h=0 <Encoding.PSEUDO_LAST_RECT: -224>

hangs forever here

Root Cause

In rfb.py, _doConnection() only calls commitUpdate() when rectanglePos is non-empty:

if self.rectanglePos:
    self.commitUpdate(self.rectanglePos)
Pseudo-encoding handlers (e.g. PSEUDO_QEMU_EXTENDED_KEY_EVENT) append to rectanglePos then immediately delete their entry. When a FramebufferUpdate contains only pseudo-encodings, rectanglePos ends up empty → commitUpdate() is never called → the Deferred from captureScreen is never resolved → infinite hang.

Fix
Always call commitUpdate() when all rectangles in a FramebufferUpdate have been processed, regardless of whether rectanglePos is empty. This ensures the Deferred is always resolved.

Test Environment
vncdotool main branch
VNC Server: TigerVNC 1.13 (Windows)
Client: Python 3.11 (Linux, Docker container)

[sibson]

thanks, ✨ 🍰 ✨