Use uploadU32DataTextureRows for LoD index uploads

[sawa-zen]

Fixes #405.

updateLodIndices duplicates the texSubImage2D path inline instead of calling
uploadU32DataTextureRows, which is already imported in this file and used a few hundred
lines above for the ordering texture. The inline copy is missing the save/restore of the
pixelStorei parameters that the helper performs.

Leaving UNPACK_FLIP_Y_WEBGL at false desynchronises three.js's WebGLState cache.
The cache still believes the value is true, so three skips the pixelStorei call before
its own uploads, and every subsequent texture is transferred with the wrong unpack state —
unrelated textures (text atlases, UI images) render vertically flipped.

Replacing the block with the helper also picks up the UNPACK_PREMULTIPLY_ALPHA_WEBGL
save/restore and renderer.state.unbindTexture(), and drops ~20 lines.

Behaviour is otherwise identical: same target texture, same 4096 x rows region, same
RGBA_INTEGER / UNSIGNED_INT upload. The renderer.properties.has(...) guard is kept, so
the "texture not found" throw inside the helper stays unreachable here as before.

Repro for the underlying issue (plain three.js, no build step):
https://sawa-zen.github.io/three-texture-flip-repro/?pollute=1

npx biome check and npm test pass. npx tsc --noEmit reports only the pre-existing
spark-rs module errors from not having run build:wasm; nothing in SparkRenderer.ts.

Note: the comment in uploadU32DataTextureRows mentions renderer.state.pixelStorei as an
alternative for three.js >= r184. Happy to switch to that instead if you prefer, but I kept this
patch to "call the existing helper" so it stays minimal.