vello: Keep image atlas residency across renders

[waywardmonkeys]

This changes Vello’s image atlas handling from per-render rebuilds to persistent residency.

Before this series, image atlas placement was recomputed on every resolve, and the renderer recreated and rewrote the atlas texture every render. That meant even steady-state scenes that only moved already-uploaded images still paid repeated atlas upload cost. This series keeps atlas residency metadata alive in vello_encoding, keeps the atlas texture proxy alive in vello, and only uploads images that are newly inserted or dirtied by atlas growth.

What changed:

• vello_encoding now keeps the single-atlas allocator and resident image map across resolves.
• Resident entries are reused by blob id instead of being repacked every render.
• Eviction uses generation-based staleness under allocation pressure before growing the atlas.
• Atlas growth still repacks, but marks residents dirty so only required re-uploads happen afterward.
• The renderer now keeps the atlas texture resident across renders and only recreates it when the atlas size changes.
• Atlas logging is quieter in the steady state, but still reports creation, resize, uploads, and eviction activity.
• Added demo scenes that make residency visible, including a large-image case that roughly fills a 4096x4096 atlas with moving images.

Use this to see the trace log messages:

RUST_LOG=vello::render=debug cargo run -p with_winit -- --test-scenes

[waywardmonkeys]

As with everything, this was done with AI assistance, but I did review it and we iterated on it some.

[waywardmonkeys]

This helps address the performance problem described in #1545.

[waywardmonkeys]

We probably need a way to mark images as dirty (mainly image_override ones) (or only them?)

[raphlinus]

I checked this over fairly carefully. Generally, it looks good, but I did have some comments; my biggest single concern is the potential panic in repack_to_size.

Just sketching, there's an alternative to the dirty bool in residents. Rather, you can have a resize_gen for the atlas, incremented on each resize. Instead of dirty, track the resize_gen for which the image was last uploaded. Then in the occupied case of get_or_insert, push & update resize_gen if resize_gen doesn't match. That avoids the full map iteration in restart_resolve_pass and eliminates the need for finish_resolve. I personally find this easier to reason about: the resize_gen in a resident identifies which gen it was uploaded to. But basically comes down to a style issue; I did verify the current logic and am satisfied.

[raphlinus]

I'm a little worried about panics here. Does guillotiere give guarantees that allocation will succeed if size is sufficient? It seems like fragmentation etc might cause a failure under reasonable circumstances.

[raphlinus]

I think continue 'outer will work here, but isn't necessarily optimal; it should be possible to retry the get_or_insert and move on. But it makes the logic a bit messier, so not sure it's worth changing.

[waywardmonkeys]

@raphlinus I've updated this per your feedback, I think. Want to take a fresh look?

[raphlinus]

Yup, looks like you addressed all my comments. Thanks!