fix(paint): sample photos from their on-screen size instead of nearest neighbour

[LeadcodeDev]

draw_image_rect with a default Paint samples with Skia's defaults: nearest neighbour, no mipmaps. A photo drawn smaller than its source keeps one pixel out of N and drops the rest, so hair and glasses alias; drawn larger it is enlarged pixel by pixel into blocks. On the issue's 640px checkerboard the 64px case is scale 1/10 exactly, every sample lands on the same parity, and the image renders solid white — measured at mean 255, min 255, max 255.

renderer::photo decides from the size the bitmap is finally drawn at rather than from its layout box: mipmapped linear when either axis minifies, Mitchell cubic otherwise, because cubic does not consult mipmaps and so is only correct when enlarging. The scale is read off canvas.local_to_device_as_3x3(), which already carries the camera, so a 640px rect under a camera at 0.1 is correctly treated as a 64px draw. Two details the diff does not explain: the axis scales are hypot(scale_x, skew_y) rather than scale_x alone, since the raw component reports a pure rotation as a shrink; and draw_photo takes impl AsRef<Image> to match Skia's own signature, which made the twenty call sites a textual swap with no borrow reasoning at each one.

Twenty sites now go through it — every place a raster bitmap is scaled into a destination rect. That is more than the issue listed: video, lottie and svg each had several, and transition::render_layer is reached through surface.canvas(). icon joins them too; it already asked for Mitchell, but unconditionally, so a shrunk icon had no mipmaps. The sites deliberately left alone all use the point form of draw_image, which places the bitmap at 1:1 so the sampling is never consulted: the full-frame composites in transition, the layer snapshots in paint_pass and render/scene, and engine/text/cosmic.rs, which CLAUDE.md records as not wired into rendering. paint_pass is the one of those that does sit under a scaling matrix, so it has the same defect — a snapshot of already-rasterised content is a different question from a photo, and it is left for one.

Cost, best of three over 300 frames at 1920x1080. Twelve 640px photos drawn at 52px: 1.01s to 1.13s. One 640px source filling the frame: 1.79s to 2.59s, which is 8.6ms a frame and is where cubic is paid for. Mipmaps are built once per image and cached on the SkImage, which is why the shrinking case barely moves. Cubic was kept rather than plain bilinear because it is what the issue asked for and what icon had already established, but the enlargement figure is the one to argue with if that trade is wrong.

Verification — six unit tests on the helper, two of which measure the old path so the fix cannot become vacuous: nearest neighbour reads 255/255 at scale 1/10 and 0-to-255 noise at 120/640, the helper reads mean 127 in both, and a 640px rect on a canvas scaled to 0.1 confirms the camera is read rather than the layout size. One integration test renders the issue's scenario through the image component and was confirmed red before the fix at mean 255.0, the figure the issue reports. Plus cargo fmt --all --check, cargo clippy --workspace --all-targets --features rustmotion/studio -- -D warnings, and cargo test --workspace --features rustmotion/studio: 2153 passed, 0 failed, 10 ignored across 53 suites.

The toolchain pin this needed is merged (#467), so this targets main and its diff is this change alone.

Closes #465