Refactor Batcher to use pre-computed UVs from region objects instead of coordinate-string lookups #1281

Description

The texture atlas currently maintains a workaround where regions are cached under coordinate-string keys ("x,y,w,h") in addUVs() so the Batcher can look them up by source coordinates. Additionally, getUVs() has a fallback that parses unknown region names as "x,y,w,h" strings and creates ad-hoc regions on the fly.

This is fragile and adds unnecessary complexity. The Batcher should work directly with region/frame objects that already carry their pre-computed UV float arrays, rather than performing string-based lookups.

Current behavior

1. addUVs() creates a duplicate atlas entry keyed by "x,y,w,h" coordinates (atlas.js:401-402)
2. getUVs() falls back to parsing the region name as "x,y,w,h" when no named region is found (atlas.js:370-372)
3. addRegion() allows creating arbitrary regions on the fly (atlas.js:285)
4. The coordinate-string cache pollutes the atlas dictionary, causing Object.assign in Sprite.addAnimation() to produce undefined entries in WebGL mode (sprite.js:409)

Proposed solution

1. Refactor the Batcher to accept region objects with pre-computed UVs directly, instead of looking up regions by coordinate strings
2. Remove the coordinate-string cache in addUVs()
3. Remove the "x,y,w,h" parsing fallback in getUVs()
4. Require proper pre-defined atlas regions via addRegion()

Locations

• src/video/texture/atlas.js — addRegion(), getUVs(), addUVs()
• src/renderable/sprite.js — addAnimation() affected by atlas pollution
• Batcher/compositor code that consumes texture regions