Claude review: lib/fonts: Store font data for user space with font_data_export()

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Potential user-visible regression for width 17-24 fonts.**

The old code for `font->width <= 24` used `sizeof(u32)` (4 bytes) as the internal pitch for reading font data:
```c
fontdata += sizeof(u32);  /* 4 bytes per scanline internally */
```
but wrote only 3 bytes to user space. The new code uses `pitch = DIV_ROUND_UP(font->width, 8) = 3` for both reading and writing.

If any existing internal font with width 17-24 stores its data with 4-byte-per-scanline alignment (which the old code assumed), the new code would read the wrong bytes. Let me check: currently there are no built-in fonts with widths in the 17-24 range, so this only affects user-loaded fonts. For user-loaded fonts, `font_data_import()` (patch 11) uses `pitch = DIV_ROUND_UP(width, 8)` which gives 3 for width 17-24. So the import and export are now consistent with each other (both use 3-byte pitch), even though they differ from the old behavior. The commit message addresses this and references user-space code, so this appears intentional.

The padding calculation:
```c
memset(data + glyphsize, 0, pitch * vpitch - glyphsize);
data += pitch * vpitch;
```
Where `glyphsize = font->height * pitch` and the padding is `pitch * (vpitch - font->height)`. This is correct.

The early return for missing data:
```c
if (!font->width || !font->height || !font->charcount || !font->data)
    return 0;
```
This returns success (0) when `font->data` is NULL, which matches the original fbcon code's implicit behavior (it would just skip the copy), but the original code had `if (!font->data) return 0;` explicitly — checking width/height/charcount is new defensive logic that seems fine.

---
Generated by Claude Code Patch Reviewer