Fixed degenerate shapes when adding a mapping right after video import

[sofian]

Summary

Stacks on #625. Importing a video and immediately adding a shape (e.g. a circle) for it could create a degenerate shape with all control points collapsed near the same point. Root cause: #625 made video import asynchronous, so right after import Video::getWidth()/getHeight() can still report -1 (no frame decoded yet) — and shape-creation (Util::createEllipseForTexture() etc.) reads those synchronously at the moment the user clicks "Add Ellipse". This is exactly the case the old blocking waitForNextBits() used to paper over by guaranteeing valid dimensions before returning.

Fix follows the same pattern already used for Syphon sources in this codebase:

• Video::getWidth()/getHeight() now fall back to a sane DEFAULT_WIDTH/DEFAULT_HEIGHT (640×480) placeholder instead of the raw (possibly -1) value from the underlying player, so a shape created before any frame arrives is never degenerate.
• New Video::frameSizeKnown(sourceId, width, height) signal, emitted once the first real frame arrives.
• MainWindow::autoFitVideoInputShapes() (mirroring the existing autoFitSyphonInputShapes()) rescales any input shape still at the untouched default size once the real resolution is known, without touching shapes the user has already adjusted.
• Also split the polling budget: detecting the first frame (which gates both the thumbnail and the shape auto-fit) now gets a much more generous 15s budget than the 1s used for the thumbnail's post-seek frame, since giving up on shape auto-fit permanently strands the shape at the wrong size, while giving up on the thumbnail just leaves a generic icon.

Test plan

• qmake6 mapmap.pro && make builds clean
• tests/ suite builds and all 44 existing Qt Test cases pass
• Standalone harness confirms: getWidth()/getHeight() return 640×480 immediately after construction (not -1×-1), and frameSizeKnown fires with the real dimensions (tested with an 800×600 source) once the frame arrives