Stop the flaky date-column test failing on the hour it runs at - #722

PBGitCommitDateFormatterTests.testTheSizingDateDoesNotDependOnToday
failed on master, and would have gone on failing at unpredictable times,
because it measured a fixed string against the clock.

• Compare the sizing date against dates written down in the test rather
  than against [NSDate date], so the result does not move with the hour
• Move the column's slack and inset next to the sizing date they apply
  to, so the test and the history controller read one definition

The failure

From run 35718227392,
on an unrelated pull request:

PBGitCommitDateFormatterTests.testTheSizingDateDoesNotDependOnToday
("199.405273438") is less than ("199.678222656")
- 'September 28, 2026 at 10:58 PM' leaves less room than today's 'September 22, 2026 at 10:56 AM'

The history column is sized against a fixed date rather than the rows on
screen, so scrolling into a longer month does not meet a clipped column.
The test asserted that this fixed date renders at least as wide as
today's, which quietly assumes no real date can be wider.

One can. The sizing date is 2026-09-28 22:58, an evening time, so it
renders "10:58 PM". Measured in the font the test uses, AM is 19.9697
points wide against PM at 19.4683. That half point is enough for a two
digit morning hour to beat it, by 0.2729 locally and 0.27295 on CI.

So the test passes or fails on the hour it happens to run at. The 05:45
runs on master pass because a single digit hour is much narrower, and
afternoon runs pass because they are PM themselves, which is why this
surfaced as an occasional flake on somebody else's pull request rather
than as a steady failure.

What this does not change

The sizing date itself, and the room the column is given on top of it.
The column is a starting width the reader can drag, and a 5% allowance
on a 200 point string is some 14 points, comfortably more than the half
point at stake. Nothing here is a real sizing defect - only the test was
wrong to compare against now.

Test plan:

• PBGitCommitDateFormatterTests passes, 209 tests overall with none
  failing
• Neither test that touches the sizing date reads the clock now, so they
  give the same answer whenever CI happens to run
• The column check is driven from PBDateColumnSlack rather than a
  number copied into the test, so it follows the constant if it moves