Allocate FreeType's and HarfBuzz's memory from the gui's Zig allocator

FreeType and HarfBuzz allocated with libc malloc, out of sight of the Zig
allocator the rest of the gui uses, so its Debug leak report and a test's
std.testing.allocator never saw them. Now every allocation the font code
makes goes through ui_malloc, ui_calloc, ui_realloc and ui_free, exported
from gui.zig over `font_allocator`:

- HarfBuzz is compiled with hb_malloc_impl and friends pointing at them.
- Each UIFont gives its FreeType library its own memory manager
  (FT_New_Library with an FT_MemoryRec_ over the same functions, then
  FT_Add_Default_Modules and FT_Set_Default_Properties: exactly what
  FT_Init_FreeType does over its malloc manager), torn down with
  FT_Done_Library.
- The shim's own UIFont and scratch arrays use them too.

C's free and realloc pass no size, so a block starts with a 32-byte header
(the caller's pointer stays 16-byte, max_align_t, aligned) holding its size
and the allocator that made it, so a block goes back where it came from
even after font_allocator is repointed. runNative points font_allocator at
the gui's gpa. HarfBuzz makes a few process-wide objects on first use and
never frees them (the default Unicode functions, the locale's language,
hb-ft's font functions); ui_font_prime makes them from the default heap
before that, so a Debug build's leak report stays about fonts. Tests do the
same: the shaping tests, and a new test that creates, rasterizes and shapes
fonts under std.testing.allocator, report any leak. Only the render thread
calls into fonts, and every allocator used is thread-safe.

It costs nothing measurable: against the previous change, 10 interleaved
rounds with an A/A pair show every scenario as fast or faster with Adwaita
Mono and Maple Mono alike, and first paint over 30 launches each matches
main.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

0 files changed, 0 insertions, 0 deletions