Undo: the budget test allows unreadable memory; docs name the 32-bit cap

the_default_budget_follows_the_installed_memory_read compares the default
budget with the 1 GiB fallback when the installed memory can't be read,
as default_history_budget does, instead of failing. The reader itself is
still checked by vectorcraft-render's installed_memory_is_read.

The undo history line in docs/target-app-parity.md says the budget is at
most a quarter of the address space in a 32-bit build.

crates/engine/src/tests/history_mem.rs

@@ -87,9 +87,9 @@ fn the_default_budget_is_a_quarter_of_installed_memory() {
 #[test]
 #[cfg(any(target_os = "linux", windows, target_os = "macos", target_os = "freebsd"))]
 fn the_default_budget_follows_the_installed_memory_read() {
-    let memory = vectorcraft_render::physical_memory();
-    assert!(memory.is_some_and(|m| m >= 256 << 20), "{memory:?}");
-    assert_eq!(default_history_budget(), memory.map_or(0, history_budget_for));
+    // Where the memory can't be read (a sandbox that hides it), the budget is the 1 GiB fallback.
+    let memory = vectorcraft_render::physical_memory().filter(|&m| m > 0);
+    assert_eq!(default_history_budget(), memory.map_or(1 << 30, history_budget_for), "{memory:?}");
     assert_eq!(History::default().byte_budget, default_history_budget());
 }
 

docs/target-app-parity.md

@@ -994,7 +994,7 @@ Moved from the ROADMAP's "Shipped so far" on 2026-10-10. Update it when a featur
   An image whose pixels can't be decoded, such as a PNG cut short or an image over the 2 GB decoding allowance as RGBA that can't be drawn at reduced size, is tried once: the renderer notes it and does not try to decode it again on later frames. An image refused only because the images being drawn leave no room for it is tried again on the next render. On the canvas such an image draws as a light gray box crossed from corner to corner, and the status bar says once for each image that it couldn't be decoded; exports leave it out and report it as before.
   A PNG, JPEG, GIF or WebP image that takes more than 2 GiB as RGBA (512 MiB in the web app) draws in the canvas and in raster exports at the largest size within that allowance, instead of as that crossed box on the canvas and not at all in exports. Each pixel of the result is the mean of the image's pixels it covers, and the document keeps the whole file. A PNG that isn't interlaced is read a row at a time, and other images are read whole when their decoded samples fit in the allowance. A 16-bit PNG that isn't interlaced, whose decoded samples take more than the allowance and whose RGBA fits in it, draws at its own size, read a row at a time. An image of more pixels than the allowance has bytes (on the desktop, 46,341 × 46,341 is more) still draws as the crossed box, and so does one whose decoded samples take more than the allowance, other than a PNG that isn't interlaced. Open, Place and the Links panel say "an image of W × H pixels is shown at reduced size", and say "too large to draw" of an image that is not drawn at reduced size.
   The renderers keep the decoded images they share within a quarter of the installed memory on Windows, macOS, Linux and FreeBSD, within 1 GiB where the installed memory can't be read, and within 256 MiB in the web build; while the decoded images add up to less than that budget, they are not decoded again when the view changes.
-  Each document's undo history keeps its steps within a quarter of the installed memory on the same systems (at least 64 MiB), within 1 GiB where the installed memory can't be read, and within 256 MiB in the web build; past that budget the oldest steps are dropped, but the last eight undo steps and the next eight redo steps stay.
+  Each document's undo history keeps its steps within a quarter of the installed memory on the same systems (at least 64 MiB, and at most a quarter of the address space in a 32-bit build), within 1 GiB where the installed memory can't be read, and within 256 MiB in the web build; past that budget the oldest steps are dropped, but the last eight undo steps and the next eight redo steps stay.
   With `--deep`, each memory row of `vectorcraft-cli perf` also gives the peak so far: the peak working set on Windows and the peak resident memory (`VmHWM`) on Linux. A new last row gives the memory after the SVG export and the save → open → save at the end of the run.
   The renderer composes the two ink planes of a CMYK document that shows transparency into screen colors on up to as many threads as it rasterizes with, instead of on one. At 2880 × 1800 on 8 threads, a page of 300 shapes at 20% to 90% opacity takes 30 ms a frame instead of 55 ms, and 50,000 paths with one at 99% opacity take 258 ms instead of 361 ms (`vectorcraft-cli bench`), with the same pixels.
   With Overprint Preview or Separations Preview on, the renderer keeps the art it prepared for the preview from one frame to the next. It prepares again the objects that changed, and all of the art when Discard White Overprint changes or, with Separations Preview, when the plates shown, the proof setup, the swatches, the Spot Colors option or the color settings change or a profile is loaded. It draws the other objects from the art, geometry and stroke outlines it kept for them.