Claude review: lib/fonts: Look up glyph data with font_data_glyph_buf()

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

Patch Review

This patch adds two functions to `lib/fonts/fonts.c`:

```c
static unsigned int font_data_num_glyphs(font_data_t *fd, unsigned int width, unsigned int height)
{
	return font_data_size(fd) / font_glyph_size(width, height);
}
```

```c
const unsigned char *font_data_glyph_buf(font_data_t *fd,
					 unsigned int width, unsigned int vpitch,
					 unsigned int c)
{
	if (c >= font_data_num_glyphs(fd, width, vpitch))
		return NULL;

	return font_data_buf(fd) + font_glyph_size(width, vpitch) * c;
}
```

I verified that internal built-in fonts correctly set up `FNTSIZE` in their `extra` array (e.g. `font_8x16.c` uses `{ 0, 0, FONTDATAMAX, 0 }` where `FONTDATAMAX=4096`, matching `256 glyphs * 16 bytes`), so `font_data_size()` will return the right value and `font_data_num_glyphs()` computes correctly.

**Minor observations:**

- The parameter naming is slightly inconsistent: `font_data_num_glyphs` calls its third parameter `height`, but `font_data_glyph_buf` calls the same parameter `vpitch`. Both mean "number of scanlines per glyph." The doc comment on `font_data_glyph_buf` correctly says "@vpitch: The number of scanlines per glyph" so this is just cosmetic, but using `vpitch` consistently would be cleaner.

- If `width` or `height` were ever 0, `font_glyph_size()` returns 0 and `font_data_num_glyphs()` divides by zero. This can't happen with valid font data and the existing code already assumes non-zero dimensions everywhere, so this is not a real concern — just noting there's no explicit guard.

- The kdoc is good and clearly documents the NULL return case.

**No bugs. Looks good.**

---
Generated by Claude Code Patch Reviewer