SdfGlyph

The single statement of this convention — nowhere else should restate it, only rely on it. These run the same direction the atlas PNG's own rows do, and the same direction createSurfaceTexture actually uploads: SurfaceTexture (both backends) does not flip an ImageBitmap source, so texture v = 0 samples the PNG's own row 0, its top. atlasTop is therefore the smaller number — nearer row 0 — and atlasBottom the larger one, unlike planeTop/planeBottom above, which are a world-space quantity and stay y-up. writeUv in sdfTextLayout.ts divides these by atlasWidth/atlasHeight and uses the result as v directly: no flip, because these already agree with what the texture does.

A version that flipped these to be y-up — matching the plane box's own sign, so that "a texel and a plane coordinate agree on which way is up" — shipped for two days (2026-08-16) and flipped every glyph onto the wrong row of its atlas, because SurfaceTexture had already stopped flipping the upload two days earlier. Two conventions that each sound reasonable alone cancelled into a bug neither side's unit tests could see, because neither one renders a real texture.