glplat: Ebitengine backend behind -tags glplat_ebiten (stacked on #392)

[mparrett]

Stacked on #392. This branch carries #392's commits rebased onto current main (one .gitignore conflict, both sides kept) plus two of ours on top; only the tip two commits are for review here. It will be rebased onto whatever #392 lands as, and closed instead if the commits get folded into #392 directly. Draft until then.

A second registry.Backend implementation, on Ebitengine instead of GLFW/OpenGL. Two motivations: prove the backend seam with an independent implementation while #392 is still a draft and the interface is cheap to change, and get the two capabilities the GL backend cannot offer — the browser (ebiten's js/wasm target; the GL backend is cgo+GLFW, native only) and modern native APIs (Metal on macOS, where the GL backend rides deprecated OpenGL 4.1).

Ebiten owns the main thread, which inverts glplat's caller-owned frame loop. The backend absorbs the inversion so the API and game code see no difference: main routes through a boot trampoline (glplat.EbitenBootMain), the lg program runs on a goroutine, and EndFrame hands each frame's batches to ebiten's Update over an unbuffered channel, which doubles as frame pacing. MVP matrices are applied on the CPU since ebiten's DrawTriangles is 2D screen-space; rendering is at device scale to match the GL backend's framebuffer resolution.

Known limitation: ebiten has no depth buffer, so batches draw in submission order. That is exact for the top-down xsofy frontend (coplanar geometry under an ortho matrix) but mis-sorts first-person-mode geometry; a CPU back-to-front sort for perspective batches is the planned follow-up.

Verified (2026-08-14):

• The unmodified xsofy GL frontend runs on this backend: XSOFY_GL_DUMP output byte-identical to the GL backend and deterministic across runs; screenshot pixel diff 0.3%.
• CPU/memory parity over a 10s run; peak RSS flat from 30s to 60s (no leak), constant ~11MB above the GL backend.
• GOOS=js GOARCH=wasm builds with the tag and a probe page running an lg draw loop renders correctly in Chromium — the blocking EndFrame contract survives wasm because the Go scheduler parks the blocked lg goroutine while ebiten's requestAnimationFrame loop runs.
• Default (untagged) build, -tags glplat, and GOOS=linux/plan9/js builds are all unaffected.

🤖 Generated with Claude Code

[nooga]

Delta itself is clean (tag-gated deps confirmed absent from the default build, both build matrices pass, nnunley approved). Parked only because it's stacked on #392, which still has an open P1. Once #392's fixes land, rebase or fold these two commits in and this is a quick approve.

[nnunley]

Architecture dependency update (2026-09-07):

#744 remains blocked behind #392, but the intended direction is now explicit: use the merged #572 surface host-capability model, put headless font support behind a separate opt-in glplat_fonts tag, and define the backend-independent frame/window/input/lifecycle contract before landing either backend.

Please do not treat this as a request for a mechanical rebase yet. #392's unresolved safety/API findings still need fixes after the re-scope, and this Ebitengine backend should be evaluated against the resulting #572-based contract rather than the current glplat registry contract.