Engine.materializePlan: what materialize will write, and its peak memory, before it starts

[davidackerman]

Adds Engine.materializePlan(view, options), which reports what materialize will write and the most memory it will hold, without computing anything. This is the follow-up the second review of #41 asked for. #41 merged before this commit was pushed, so it comes as its own PR.

With it, a page can warn before a large box starts, or offer to snap the box to the chunk grid along one axis.

MaterializePlan has these fields:

• shape and chunk: the array's shape and chunk shape, channel axes first.
• total: the array's chunks.
• needed: the served chunks it computes, each once.
• split: the axes the box splits.
• walk: the walk's axis order, outermost first.
• chunkBytes.
• peakChunks: the most box chunks held at once.
• peakBytes: peakChunks × chunkBytes. This leaves out the up to concurrency served chunks in flight, as the docs say.

The same plan is available without an Engine, as plan(region(...)). materialize and materializePlan share how the region is built (regionOf).

peakChunks is the walk's exact count, not just the documented bound.

• The bound is n2·n3 + n3 + 1 with three split axes, n2 + 1 with two, 1 with one and 0 with none. It is exact whenever every split axis has three or more of the box's chunks.
• Where one axis has fewer, every axis inside it has at most two, and those are counted directly.
• So the plan never says more than the walk holds. The bound alone overcounted 20 of 3,000 random boxes.
• It takes about 0.1 ms for a 10k³ box.

Tests. The projected peak equals the walk's measured count:

• for each alignment, with three, two, one and no split axes (13, 4, 1 and 0 chunks);
• for the wide, shallow box (23) and a box on a chunk edge along y (3);
• for 400 seeded random boxes.

There are also two plan checks: the full plan of a 2-channel float32 box, and that the level's extent plans a peak of 0.

Docs.

• formats.md describes materializePlan next to the bound. It also records the review's preferred fix, should a smaller peak ever matter: compute the plane of served chunks that two slabs share twice, along the outermost split axis, rather than compressing waiting chunks or refusing the box.
• design.md and the CHANGELOG mention the plan.
• Two over-long lines from Browser engine: Engine.materialize writes exactly the box, stitched from the served chunks (extent: "box", the default) #41 in caching.md and design.md are rewrapped.

Checks: npm run check in web/ passes (typecheck, 71/71 tests, build), as do mkdocs build --strict, pytest -q tests/test_docs.py and ruff.