Clamp oversized imagery tiles to maximum texture size

[TJKoury]

Imagery providers can return tiles larger than the GPU's MAX_TEXTURE_SIZE (e.g. 8192 on Firefox vs 16384 on Chrome). When this happens, the Texture constructor throws a DeveloperError with no recovery path, breaking tile rendering.

This adds a downscale step in ImageryLayer._createTextureWebGL that clamps non-compressed imagery to ContextLimits.maximumTextureSize via an offscreen canvas before texture creation. Compressed textures (KTX2) are unaffected since their dimensions are typically controlled by the provider.

Testing: Reproduced on Firefox (MAX_TEXTURE_SIZE=8192) with a WMS provider serving large tiles. After this fix, oversized tiles are downscaled transparently instead of throwing.

[github-actions]

Thank you for the pull request, @TJKoury!

✅ We can confirm we have a CLA on file for you.

[ggetz]

Thanks for the PR @TJKoury! @javagl would you be able to review?

Assuming we agree on the improvement, could we get an update to CHANGES.md and maybe a unit test?

[javagl]

The change looks small, local, and straightforward. I cannot imagine any issues with that.

(Well, of course I can. Someone will create an imagery provider that serves 32768x32768 pixel images that are completely white, and have one black pixel at the lower right border, and then complain that this "rectangle grid" that they expect there does not appear, because the scaling is rounding away that black pixel - let's way for the issue report of this case)

Unit tests for this could be tricky - at least, they won't run in CI, and given the platform-dependency, one might have to use some "mock ContextLimits". Related to that: Is there an "easy" way to test this? (I can try to create or set up some "dummy image server", but wondered whether someone has already an off-the-shelf solution for that)