Stale SetPixels32 exact-length comments in the sprite tools; block overload tolerates oversized rents

[wallstop]

What happens

Four Editor/Sprites sites carry why-comments claiming Texture2D.SetPixels32 requires exact-length arrays:

• Editor/Sprites/SpriteCropper.cs:936 — "SetPixels32 requires exactly width * height elements, so an oversized pool buffer cannot be passed directly."
• Editor/Sprites/SpriteSheetExtractor.cs:7078 — "SetPixels32 requires exact-length arrays; WallstopFastArrayPool supplies them without oversized buckets."
• Editor/Sprites/SpriteSheetExtractor.cs:7571 and :7708 — "SetPixels32 requires exact-length arrays, so oversized SystemArrayPool buffers cannot be used directly."

The claim is true only of the whole-texture overload, which throws ArgumentException on an oversized array. Measured on 6000.4.6f1, the block overload SetPixels32(0, 0, width, height, oversizedArray, mip) accepts an oversized rent and writes exactly the requested block — byte-identical to the exact-array call at 5x3, 16x16 and 1x1, mip chain on and off, across RGBA32/ARGB32/RGB24.

Why it matters

The comments are the package's recorded reason to avoid pooled rents at these sites, and at least one (SpriteSheetExtractor.cs:7078) is used to justify a bespoke exact-size pool (WallstopFastArrayPool), whose per-size bucket retention the pooling skill flags as the pool shape to avoid. The stated constraint does not hold, so the sites may be able to use the ordinary SystemArrayPool rent and delete the exact-size machinery.

What to do

1. Reword the four comments to the true statement: the whole-texture SetPixels32 requires exact-length arrays; the block overload takes a count and tolerates oversized rents.
2. Measure SpriteCropper/SpriteSheetExtractor against the block overload on the floor editor (2021.3.45f1 — the oversized tolerance is verified on 6000.4.6f1 only, and the 2021.3 floor is the typecheck pin), then switch the sites if clean.
3. If the switch lands, delete the exact-size WallstopFastArrayPool usage it existed for and record the measurement next to the block-overload row in .llm/skills/unity-api-costs.md.

Acceptance

• No comment in Runtime/ or Editor/ states the exact-length rule without naming the whole-texture overload.
• The block-overload measurement carries a floor-editor (2021.3) data point, not only 6000.4.6f1.
• Sprite tooling output is byte-identical before/after on real sprites (existing sprite editor tests plus a before/after comparison).

Provenance

From the PR #749 buffered-pixels review thread (#749 (comment)): the write side was prototyped as a pooled rent and rejected there on retention/cap grounds for SpriteHelpers itself, but the audit also surfaced that these four editor sites' justifying comments overstate the API. Deliberately left alone in #749 to keep the change scoped to runtime code.