Line up the elements of a history row - #683

Fixes #679.

The subject was nudged a point above centre by hand, and only on rows that had a graph line, so it lined up neither with the columns beside it nor with the ref labels next to it.

• Centre the text field on the row instead of offsetting it, and lay every row out rather than only those with a graph line, which left the rest wherever the nib happened to put them.
• Snap the result to the backing grid with -backingAlignedRect:options:, replacing the hand-rolled floor() calls.
• Give the short-SHA column a font whose metrics agree with the columns beside it, and drop it a point so its digits sit level with them.
• Add tests over the rectangles the cell lays out, since none of this drawing is checkable any other way.

Why the ref labels are untouched

The issue suggested the label text sits low inside its capsule. Measured against the capsule the cell actually draws, it does sit slightly low, by an amount that depends on the branch name:

That spread is inherent rather than a bug. The capsule is the measured line box, 13.0pt for every one of those strings and so the same in every script, and the baseline works out to cap-height centring, which is what keeps master and MASTER sharing a baseline instead of drifting apart from each other. Centring each label's own ink would break that.

What is worth a separate look is clearance rather than placement: the capsule hugs the line box exactly, so a descender lands on the border with nothing under it. That is visible on origin/master. Fixing it means padding the capsule vertically, the way ref_padding already pads it horizontally, and it moves every label rather than only the ones in this issue, so it does not belong in this change.

The short SHA column

With the subject centred, the SHA stood out as the one column still off. It is the only monospaced cell in the row, and Menlo's ink sits higher inside its line box than the proportional font beside it, so centring the two line boxes identically still leaves the digits high.

Monaco at the same size puts the ink lower in the box, and its centerY constant goes to 0 where every other column sits at -1, which is the remaining point. That the SHA is deliberately a point below its neighbours is the trade: the eye follows the digits, not the box they sit in.

This part was settled by measuring screenshots of a real build pixel by pixel, one change at a time, rather than by reasoning about font metrics, which twice pointed the wrong way.

Why the backing alignment matters

Centring a 17pt text field in a 20pt row lands on 1.5. On a 2x display that is three whole device pixels and renders crisply; on a 1x display it is half a pixel and the text renders visibly blurred. Asking the view to align the rect covers both without special-casing either, and a test pins it so a later change cannot quietly put the subject back off the grid.

Test plan

• 4 new tests in PBGitRevisionCellLayoutTests, all of which fail before this change: the subject was at midY 9 against a row centre of 10, and 7 on a row with no graph line.
• The odd-height case asserts the frame equals its own backing-aligned self, which is what the 1x blurring came down to.
• Full suite: 145 tests, 0 failures.
• Built and run against this repository to look at a real row, before and after.