Add tests for the index refresh and staging wiring - #576

Follows up on #571, where you asked for tests covering those changes.

Of the three commits that landed there, only 777e6784 carried tests, and
they cover the pure reconcile seam rather than what surrounds it. This adds
nine cases for the rest:

• Staging reads the index back (24849b90) - staging and unstaging ask
  git and then re-read, a rejected update-index reads nothing back, and
  staged paths reach git NUL-terminated
• A refresh announces the index only once it has been reconciled - the
  ordering change folded into 777e6784; neither the success nor the
  failure arm of a per-command result may announce an index update
• Overlapping refreshes coalesce (74197e56) - a request arriving
  during a refresh is deferred rather than discarded, and a burst collapses
  into exactly one re-run

Notes for review

No repository on disk, no git process, no FSEvents, no async settling. That
works because -[PBGitRepository init] touches nothing outside itself, and
the two collaborators that would otherwise reach the filesystem are ordinary
overridable methods, so test-local subclasses record the calls instead of
making them. The whole suite runs in about two seconds.

One production change: the refresh guard in -refresh and its other half in
the completion block are extracted into -beginRefreshOrDeferIt and
-endRefreshTakingDeferred, so the coalescing contract can be asserted
directly. Same logic, same serial queue, just named.

Being straight about what the coalescing cases are: a contract test for the
state machine, not a reproduction of the original bug. Losing the settling
event of a rebase burst only reproduces against a real repository on disk,
and was verified by hand for #571. The other two groups do fail against the
pre-fix code.

The GitXTests target gains a header search path for Classes/Util, which
PBGitRepository_PBGitBinarySupport.h needs.

Test plan

• xcodebuild test -workspace GitX.xcworkspace -scheme GitX -only-testing:GitXTests
  • 23 tests pass, 14 existing plus 9 new, in ~2s
• Each new case was checked to be load-bearing by breaking the behaviour it
  guards and confirming it goes red:
  • removing the [self refresh] after update-index fails the two staging
    cases on the read-back count
  • restoring [self postIndexUpdated] in postIndexRefreshSuccess:message:
    trips both inverted expectations
  • dropping the deferred request instead of re-running it fails both
    coalescing cases, while the "nothing was deferred" case correctly stays
    green