Take the re-cut GhosttyKit build-2026-09-26 so the partly revealed top row can be selected

[thdxg]

With smooth scrolling on, a pane whose height isn't a whole number of cells draws a partial scrollback row at its top. Fork PR 9 made that trade on purpose so resizes slide instead of jumping. That row couldn't be selected: a press or drag on it selected the row below instead. After a Ctrl+L it is the old prompt line, sometimes nearly all of it when the leftover height is close to a cell (easy to hit in the quick terminal).

Fix in the fork: thdxg/ghostty#17. Selection now resolves the pointer to a pin. A viewport coordinate can't go above the viewport's first row, so a point in the revealed strip resolves to the row drawn there, using the same shift the renderer draws (RenderState.Shift.rowsAboveAt). That PR re-cut the fork's build-2026-09-26 tag onto its merge commit (9117b1d). The tag name doesn't change, so this PR edits the pin's comment in scripts/setup.sh: CI's GhosttyKit cache key hashes that file and refetches. The Animations section of AGENTS.md now records the rule.

A local checkout holding the earlier copy of the tag needs rm -rf GhosttyKit.xcframework Macterm/Resources/terminfo && mise run setup once.

Verified against the downloaded build in a hermetic debug instance: 42px cells, 32px top padding, 14px leftover. After 150 numbered lines and a Ctrl+L at a nushell prompt, a synthetic click-drag through the view's own mouse handlers at every point from y = 0 to 47pt selects ❯ (the partly drawn old prompt) from 0 to 22pt, and the first viewport row from 23pt on. The build this replaces selected the first viewport row across the whole strip. The before/after table and the frame check are in thdxg/ghostty#17.

[github-actions]

Window-state benchmark

State	Metric	main (median of 10 runs)	this branch	Δ
focused	CPU %	0.50	0.20	-60%
	Memory (RSS MB)	110.3	110.1	-0%
	CPU ms/s (powermetrics)	4.4	2.2	-49%
	Wakeups/s (powermetrics)	68.0	57.7	-15%
workload-focused	CPU %	2.20	2.60	+18%
	Memory (RSS MB)	146.1	140.6	-4%
	CPU ms/s (powermetrics)	20.8	23.8	+14%
	Wakeups/s (powermetrics)	174.2	198.8	+14%
workload-unfocused	CPU %	2.05	2.20	+7%
	Memory (RSS MB)	148.7	145.5	-2%
	CPU ms/s (powermetrics)	20.2	20.4	+1%
	Wakeups/s (powermetrics)	167.1	182.6	+9%

Reported value is the median of 3×10s windows per state (splitting the window and taking the median keeps one co-scheduled spike from skewing a state); CPU % is the process CPU-time delta over a window. Runs land on different shared runners, so treat small deltas as noise — 🔺/🔻 marks changes ≥25% that also clear the metric's absolute noise floor (CPU % ≥0.5, Memory (RSS MB) ≥25, CPU ms/s ≥5, Wakeups/s ≥50); CPU deltas off a noise-dominated baseline aren't flagged (CPU % baseline ≥1.5, CPU ms/s baseline ≥15). The benchmark:regression / benchmark:improvement label needs corroboration — ≥2 flagged metrics in the same direction, at least one under workload — so a lone noisy cell shows its arrow here without tagging the PR.

The baseline column pools the last 10 successful main runs (newest main@839b00ab4) as a per-metric median, so one anomalous main run can't skew the reference.