Fix framebuffer console: scroll drift causes progressive line overlap in TTF mode

fb_scroll_rows() hardcoded the pixel distance it physically shifts the
framebuffer by as char_rows * 16 * scale -- the bitmap-font (font_8x16.c)
cell height -- regardless of which glyph mode vt100.c actually had active.
In TTF mode (the REPL's default, cell height 24px via VT100_TTF_CELL_H_PX)
this meant every scroll_up(1) call physically shifted the framebuffer by
only 16px while the text model (g_vt.rows, py_of()) placed each row 24px
apart. That 8px-per-scroll shortfall compounds with every subsequent
scroll: a few scrolls barely show it, but enough scrolls -- or scrolling
quickly, which is just many scrolls in a short span -- accumulates into
visible pixel overlap between rows, with newer lines drawn on top of the
tail end of older ones.

fb_scroll_rect() (the box-confined scroll added later for 4.4t) already
carried a doc comment calling this out explicitly, describing its own
explicit pixel_rows parameter as the fix for fb_scroll_rows()'s "fixed
16px-row assumption" -- fb_scroll_rows() itself was just never updated to
match.

Fixed by changing fb_scroll_rows()'s parameter from an implicit char_rows
count to an explicit pixel_rows count (matching fb_scroll_rect()'s
existing convention), and having its one caller (vt100.c's scroll_up())
pass lines * cell_h() -- the real active cell height -- instead of a raw
line count for the callee to guess at.

Verified: booted amd64 to the REPL (TTF mode active per sk_repl()'s own
console_fb_enable_ttf() call), let boot chatter + WORDS output scroll the
screen through thousands of accumulated scroll_up() calls, then measured
every visible line's y-position via a QMP screendump. Spacing held at a
perfectly consistent 24px (TTF cell height) top to bottom with zero drift
-- the old hardcoded-16px bug could not have produced that after this many
scrolls. Re-verified boot to ok> on all three architectures
(amd64/aarch64/riscv64) per repo acceptance policy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

include/starkernel/framebuffer.h

@@ -100,16 +100,22 @@ void fb_draw_orientation_test(void);
  * --------------------------------------------------------------------- */
 
 /**
- * Scroll the framebuffer up by `char_rows` character rows (each 16 px).
- * The vacated rows at the bottom are filled with bg.
+ * Scroll the whole framebuffer up by `pixel_rows` pixel rows. The vacated
+ * rows at the bottom are filled with bg. Takes an explicit pixel-row count
+ * (not a hardcoded 8x16-cell assumption) so callers with a non-8x16 cell
+ * height (e.g. TTF mode, 24px) pass their own cell height directly --
+ * same convention fb_scroll_rect() below already uses, for the same reason
+ * (a caller-computed char_rows * fixed-16px assumption drifts out of sync
+ * with the text model's own row height in TTF mode, and that drift
+ * compounds with every scroll).
  */
-void fb_scroll_rows(uint32_t char_rows, uint32_t bg);
+void fb_scroll_rows(uint32_t pixel_rows, uint32_t bg);
 
 /**
  * Scroll a sub-rectangle of the framebuffer up by `pixel_rows` pixel rows
  * (FABRIC.md item 4.4t: box-confined REPL scrolling). Unlike fb_scroll_rows()
- * (whole-framebuffer, fixed 16px-row assumption), this is bounded to
- * [x, x+w) x [y, y+h) and takes an explicit pixel-row count so callers with
+ * (whole-framebuffer), this is bounded to
+ * [x, x+w) x [y, y+h). Both take an explicit pixel-row count so callers with
  * a non-8x16 cell height (e.g. TTF mode) pass their own cell height directly.
  * Pixels outside the rect are untouched. The vacated rows at the bottom of
  * the rect are filled with bg.