Render preview: draw within the pixel budget on 4K/5K screens (#1464) (#1477)

The product preview asked the viewport executor for the full physical
viewport, so a maximised 4K window (~8 MP) was refused against the 4 MP
limit on every frame. The preview now draws at the largest size of the
same aspect the executor admits (RenderLimits::fit, scratch included)
and filters it up into the viewport through the existing offscreen
blit. Viewports within the limits still draw at full size.

PNG setups past the image limits now say what the limits are and the
largest size at that aspect, and the image panel offers to use it.

Co-authored-by: Claude Opus 5.5 <[email protected]>

docs/render-workspace.md

@@ -65,6 +65,16 @@ per dimension and 4,194,304 pixels, within the 256 MiB pixel scratch admission p
 The estimate includes the selected MSAA colour/depth cost; it excludes scene geometry,
 driver overhead and cached source meshes. It is not a measurement of total GPU memory.
 
+The preview never refuses a frame because of the screen size. When the viewport's physical
+size is past those limits (a maximised 4K or 5K window is 8–15 million pixels), the preview
+draws at the largest size of the same aspect the executor admits (`RenderLimits::fit`, both
+axes scaled by one factor, scratch included) and filters it up into the viewport. A viewport
+within the limits draws at full size.
+
+PNG images keep the saved-setup limits above. A setup past them is refused with the limits and
+the largest size at its aspect (for example `4096 × 4096` → `2048 × 2048`), and the image panel
+offers to use that size.
+
 Pure capability metadata lives in the session/host, outside persistence and history,
 surviving document replacement, scratch sessions and document-tab switches. No wgpu
 types enter the engine or document crates. A host without an installed GPU/depth buffer