LR-IMP-FORMATS: GIF density from the first frame; mostly blank canvases capped at 4 MP

From echelon's review of #2607:

- A GIF's LZW data now bounds its first frame's own width x height, not the logical screen's,
  so a valid GIF with a small first frame on a larger screen imports.
- A canvas the file's data leaves mostly blank (a GIF screen larger than its first frame, or an
  RLE BMP larger than its runs could cover at 255 pixels per 2 bytes) still costs its whole size
  in from_decoder, so it is limited to 4 MP (SPARSE_MAX_PIXELS) and refused before the decoder
  allocates it. Densely coded canvases keep the max_pixels limit.

Tests: a 64-byte RLE BMP declaring 2001 x 2000 or 32000 x 32000 is refused ("mostly blank");
the RLE BMP that ends early still opens at 2000 x 2000; a GIF with a 1 x 1 first frame opens on
a 2000 x 2000 screen and is refused on a 32767 x 32767 one. The first three fail without this
change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PtjHGt5gnCHXgLt4NbGorf

docs/whats-new.md

@@ -7,8 +7,9 @@
   now refused with an error when importing or opening it (issue #2553). Before, LightCraft set aside memory for the
   whole picture, several gigabytes, and could close without warning, losing unsaved work. At import, a GIF or BMP
   picture larger than 4 megapixels now has its size read from the header instead of being decoded; smaller ones are
-  still decoded, so a damaged file is caught then. A run-length-encoded BMP that ends early, leaving the rest of the
-  picture blank, still opens.
+  still decoded, so a damaged file is caught then. A picture that is mostly blank (a run-length-encoded BMP that ends
+  early, or a GIF whose first frame is smaller than the picture) still opens up to 4 megapixels; a larger one is
+  refused, because opening it would still set aside memory for the whole picture.
 
 ## 2026-10-21