Refuse loads and renders that would not fit in memory

Opening a project of ninety 17 MP photos got Effector killed by the
kernel's OOM killer: 4.6 GB of decoded RGB on a machine with 3.6 GB free,
and no core dump to show for it. Bulk allocations are now sized first and
refused with an OutOfMemoryError past three quarters of the free memory
(MemAvailable, or less under a cgroup memory.max). loadImages sizes the
batch from the file headers and refuses it before decoding anything, and
holds the decodes in flight to what is left; renderChain and renderFrames
refuse a canvas at 24 bytes a pixel, plus any picture a Path param loads.
The interface keeps a refused batch's paths, so saving the project never
drops them. Version 0.6.1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -4,6 +4,17 @@ Every release of Effector, newest first. The version lives in one place, the
 `project()` line of `CMakeLists.txt`, and each release is a `vX.Y.Z` tag on the
 commit that made it. The interface shows this file under Changelog in its menu.
 
+## [0.6.1] - 2026-09-26
+
+### Fixed
+- Opening a project whose images would not fit in memory no longer gets
+  Effector killed by the system. The images are measured before any is read,
+  and a batch that would not fit is refused with a message saying how much it
+  needs; the images stay in the project, so saving it keeps them.
+- A canvas too large to render in the free memory is refused the same way,
+  in the interface and on the command line, instead of taking the machine's
+  memory down with it.
+
 ## [0.6.0] - 2026-09-26
 
 ### Added