M7: fold repeated group moves of a cropped image into one clip cm (#2476)

Moving an image whose crop is its own (`q re W n cm Do Q`) as part of a
group put a fresh `cm` before the clip path on every move, so twenty
moves left twenty `cm` operators in front of one `re`. It never nested
deeper, but the content stream grew with every drag.

When a `cm` already sits right before that clip (one an earlier move
added, or the file's own), `translate_images` now replaces it with the
product of the new and old matrices. The CTM at the clip is
`c · prev · outer` either way (ISO 32000-1 8.3.4, 8.4.4). A previous
`cm` that is not finite, or a product larger than 1e12, keeps the old
behaviour and inserts a separate `cm`.

The new test moves an image cropped smaller than itself twenty times and
checks that the image and its visible crop both moved by the full offset,
that the operator count stays at its value after the first move, and that
the caption after it is untouched. It fails without this change
(32 operators against 13).

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

docs/editing-images.md

@@ -8,7 +8,8 @@ together with its pixels, including nested graphics states, intervening state op
 and paths split across content streams. A clip shared with other content stays where it is.
 When the figure already sits alone in a `q … cm … Q` (its own placement, or the one an
 earlier edit added), moving or resizing it again changes that `cm`, so repeated edits don't
-nest one more graphics state each time.
+nest one more graphics state each time. Moving a privately cropped figure again likewise
+changes the `cm` before its clip instead of adding another.
 
 PDF figures are not always bitmap images. Imported diagrams often use a **Form XObject**,
 which packages text, vector paths, and nested images into one object. PdfCraft selects