fix(renderer): column-align wide-glyph cells in libghostty-vt snapshots

[ThomasK33]

Fixes #112.

Problem

Wide characters (CJK/emoji, native cell width: 2) misaligned per-cell rendering: in a line containing a wide glyph, every cell after the glyph shifted one column left, and the dashboard cursor-cell highlight landed on the wrong cell.

I verified the report against the source and reproduced it against the real native engine (in-process, no host needed):

"rocket 🚀 done" — native cell records:
  col=6 width=1 " "
  col=7 width=2 "🚀"     ← width-2 glyph
  col=9 width=1 " "       ← NOTE: no record for col 8
  col=10 width=1 "d" ...

The native engine emits one width-2 record and no record for the trailing column. mapNativeCells packed one array entry per record and dropped the native col/width, so the packed array was one entry short and cells[col] no longer matched terminal column col past the glyph.

Root cause

• src/renderer/libghosttyVt/backend.ts — mapNativeCells discarded col/width.
• src/dashboard/liveViewProjection.ts — SnapshotGrid.cellAt indexes cells[col] as the terminal column, and the cursor flag compares sourceCol === cursorCol (a true column). The dashboard pins libghostty-vt (PRD [codex] Harden darwin runtime checks #29/feat: replace ESLint and Prettier with Oxc tooling #71, ADR 0006), so it hit this by default for any screen containing wide glyphs.

Fix (no protocol-schema change)

Pack cells column-indexed in mapNativeCells: place each record at its true col and emit an empty spacer for every trailing column a wide glyph covers (and defensively for any gap). The spacer carries the glyph's styling so the trailing half shades correctly. This reuses the exact col/width the native engine already provides (no text-width measurement needed) and matches the ghostty-web backend, which already emits one cell per column — so the two renderers are now consistent and the consumer's index-as-column assumption is correct. visibleLines text was already right.

This deliberately avoids option (a) from the issue (adding col/width to the public SnapshotCell schema); that remains a possible future addition if a consumer ever needs explicit width.

Verification

• Producer (real native engine): a new availability-guarded unit test drives LibghosttyVtBackend.snapshot({includeCells:true}) — the same path agent-tty snapshot --include-cells --renderer libghostty-vt and the dashboard use — feeding a real 🚀 and asserting the glyph sits at its true column with an empty spacer after it.
• Producer (mock records): asserts both the emoji case and a two-wide-glyph CJK case (A漢字B → B stays at true col 5, previously off-by-2).
• Consumer: a projectLiveView test asserts a wide-glyph row renders column-aligned and the cursor highlights its true column (the bug highlighted the next cell).
• npm run typecheck, npm run lint, npm run format:check, full unit suite (1212 passed), and npm run build all pass locally. The e2e/integration host-dependent suites run in CI.

Existing cell tests used only ASCII/width-1 records (and the projection test helper built cells by code-point index), which is why this slipped through.

🤖 Generated with Claude Code

[ThomasK33]

@codex review

[ThomasK33]

@claude review