Feature request: offset/region support in RenderParams for atlas-style rendering

Use case

I'm building a UI system where individual nodes are cached as rasterized
regions in a shared texture atlas (for performance reasons — avoiding
recomputation of unchanged nodes across frames). The atlas is a single
persistent wgpu::Texture, and I need to update individual regions
without affecting the rest of the atlas.

Currently, Renderer::render_to_texture always clears and rasterizes
the full width×height area specified in RenderParams, with no way
to target an offset sub-region of a larger texture. This means I have
to render each node into a separate small "scratch" texture at the
origin, then use copy_texture_to_texture to composite it into the
atlas at the correct position — an extra render+copy step per updated
node, instead of a single direct render into the target region.

What I'd like

Some way to render a scene into a sub-region of a texture — e.g. an
offset: (u32, u32) field on RenderParams, or an equivalent method
that lets the coarse rasterization stage target a region rather than
always starting at (0,0).

Prior art in this repo

I noticed vello_hybrid already added render_to_atlas and
write_to_atlas APIs for glyph caching (mentioned in the v0.0.7
changelog, PR #1458). Would it be reasonable to bring an equivalent
capability to the main vello crate, or is there a reason this is
scoped to vello_hybrid specifically (e.g. related to its
CPU-preprocessing architecture vs. the pure compute-shader pipeline)?

Happy to provide more context on the atlas-caching use case if useful.

Start with the Renderer::render_to_texture entry point and RenderParams, then compare vello_hybrid's render_to_atlas and write_to_atlas APIs and PR #1458. Determine whether main vello can target an offset region without the scratch-texture copy step, and define how completion would be validated for atlas rendering.