fix multiply_bounds for odd-sized windows

[pjreddie]

Summary

• multiply_bounds was floor-dividing each coordinate independently, which made the output size depend on absolute position and raised ValueError for odd dimensions (e.g. 127x127 windows with zoom_offset=-1)
• switched to ceiling division on width/height so any window size works and output is deterministic
• added tests for multiply_bounds (even, odd, denom=4, position-independence, numerator path)

Context

hit this materializing a 29k window dataset where all windows were 127x127. the 10m bands materialized fine but all 20m/60m bands failed since 127 isn't divisible by 2 or 4. the old datasets built before the resolution factor validation was added worked fine, new ones don't.

Test plan

• existing tests pass
• new multiply_bounds tests cover even division, odd division (127/2=64, 127/4=32), deterministic size across offsets, and numerator path

🤖 Generated with Claude Code

[favyen2]

One issue is that this means that GeoTIFFs at coarser resolutions for these windows won't correspond exactly to the window extent. It may need more thought whether the error message should be more helpful but still raise error or if it should do this ceiling operation; for 127x127 windows one solution is just storing all bands at the window resolution (like 10 m/pixel).

[favyen2]

Hadrien is adding spatial_size option in #564

I wonder if that would address the same issue encountered in this PR?

Basically instead of specifying a factor for the resolution, it supports setting the width/height you want the data to be materialized at. Then the resolution is computed based on the width/height and window extent.

This has the advantage of making sure the materialized GeoTIFFs still correspond exactly to the window extent.

Alternatively for odd-sized windows you could store all the Sentinel-2 bands at 10 m/pixel.

[pjreddie]

how did this work previously? it used to not be a problem, I've always materialized odd size images because we have one center pixel labelled and we want 63 (or some odd number) of pixels on each side so we can take 64x64 crops and they always have the label pixel in them. this worked until the changes in December/January I think

[favyen2]

I'm not sure, it might've created 32x32 GeoTIFF that goes beyond the window bounds before.