v0.13.0 — display scale across the bridges

Feature

adapter.displayScale() — the factor a caller multiplies HUD and menu metrics by, so a control keeps a consistent physical size across densities instead of keying off pixel counts. Reported by the window backend through the bridge each frame. Closes #32.

The contract, and why the number differs per bridge

It is "what callers multiply by", not "the display's density" — because the bridges do not hand ImGui the same coordinate space:

bridge	ImGui coordinates	displayScale()
bgfx	physical framebuffer, 1:1 DisplayFramebufferScale	the density — callers multiply
sokol	logical units (sokol_imgui divides by newFrame(.dpi_scale))	1.0 — already normalised
raylib	rlImGui exposes no DPI	1.0 — renders 1:1 as before

A caller writes the same code on all three and gets the right physical size.

Returning the DPI on the sokol bridge was a double-apply: metrics arrive already density-normalised there, so a caller following the documented contract rendered every control DPI times too large. Fixed before release.

Pairs with

labelle-bgfx v0.18.0, which adds the window.displayScale() this consumes.