Report real cell pixel dimensions before the first redraw - #643

Kitty graphics images placed by a program's first output come out
stretched: a square image renders about 2.5 times too tall on a 9 by 23
pixel cell. The program is not at fault. It asked for the cell size
(XTWINOPS CSI 16 t) at startup and the terminal answered 1;1.
Renderer.init seeds the terminal with a 1 by 1 placeholder cell, and
the real cell geometry a resize carries is only queued until the next
redraw commits it. The first redraw happens only after the first PTY
output arrives, so the reply is wrong exactly when startup queries run.
The full investigation and a reproducer are in #642.

Renderer.resize now applies the cell pixel geometry immediately,
against the current grid, so the seeding call in ghostel--init-buffer
takes effect before the process starts. The row and column commit stays
deferred to the next redraw for scrollback promotion, as before, and
the CSI 14, 16, and 18 t replies stay mutually consistent while a grid
change is pending. The pixel fields are written directly rather than
through Terminal.resize because that call also resets synchronized
output mode, which Renderer.redraw relies on to suppress rendering
while a program holds mode 2026. This is the same class of bug as the
ghostel-compile 1 by 1 cell fix in 0.49.0.

A new ERT test creates a terminal, seeds the cell dimensions the way
ghostel--init-buffer does, and checks the CSI 14, 16, and 18 t replies
before any redraw, plus their consistency while a grid resize is
pending. It fails on main and passes with this change. The Zig unit
tests, the full elisp suite, and make lint pass on macOS with Zig
0.16.0 and Emacs 31.0.91. Running the patched module in a live Emacs,
a cold CSI 16 t query in a fresh terminal answers the same as a warm
one, and CSI 14 t reports real pixels instead of echoing the grid
size.

The ws_xpixel/ws_ypixel fields of TIOCSWINSZ are still sent as
zero; the issue notes that gap as optional and this change leaves it
for a follow-up.

Fixes #642