PBGitWindowWiringTests fails when the app was left on the stage view #703

The tests expect the application to be showing the history view. The
screenshot tests, which run earlier in the same CI job, leave it showing
the stage view. Which view the window opens on is a preference that
outlives them both, so the wiring tests inherit the wrong one, and from
that point every rerun fails the same way.

Put briefly: #579 built the trap, #695 sprang it.

• Fix the history list selection fighting the sidebar branch #579 added PBGitWindowWiringTests, in aadd34e4. The suite has
  depended on whichever view that preference names since the day it was
  written, but nothing ever set it, so it never fired.
• Fix the screenshot tests all photographing the same view #695 added the view switching to the screenshot tests, in fe42261d
  (for Screenshot tests capture the same view three times #676), merged as b54bb4b3. From that commit on, the screenshot
  tests leave the application on the commit view, and the preference is
  persisted.

So the failure is a property of what ran before these tests, not of the
machine's load and not of the branch under test.

Split out of #643, which was filed for a different failure in the same
test class. See the note there.

The wiring

The window shows one content controller at a time, and
-changeContentController: loads a nib only for the controller it is
about to show, by asking that controller for its view. Which one is
shown is decided in PBGitSidebarController:

if ([PBGitDefaults showStageView])
    [self selectStage];
else
    [self selectCurrentBranch];

PBShowStageView is persisted in the app's defaults domain, and
PBGitSidebarController writes it whenever the Stage row is selected.
So when a GitX has been left on the stage view, these tests build a
window whose history nib never loads. commitController and
commitList stay nil, -historyListSelecting: sets content on nil,
and three assertions fail:

PBGitWindowWiringTests.m: ((history.singleCommitSelected) is true) failed
  -[testTheFocusedHistoryListNamesTheBranchOnItsSelectedCommit]
  -[testACommitCarryingTwoBranchesNamesNeither]
PBGitWindowWiringTests.m: ("(null)") is not equal to ("refs/heads/branch_one")

A diagnostic build reports the state as history: set, commitController: nil, content: 0, selectionIndexes: (null). An array controller answers
an empty index set rather than (null), so the outlet is nil rather
than the selection being empty.

How CI sets it

The screenshot tests drive the real application and switch to
View > Commit. Test methods run alphabetically, so
testStagingTabScreenshot runs last of the four and never switches
back, leaving the app on the stage view and the preference set in the
defaults domain shared by every GitX on the runner. The workflow then
launches that app in Build baseline and run its UI tests, and the
later Run tests step re-runs GitXTests in the same job, where they
inherit it.

Evidence

One CI job, one build, one variable at a time:

It reproduces on an idle machine, macOS 15 included, with no CI involved:

defaults write net.phere.GitX PBShowStageView -bool YES
make unit-test ARCH=arm64

Two of the six cases fail and the other four pass. The failing cases
take well under a second, which is what rules out load: a load problem
shows up in the 30 second waits, not in these assertions.

Two details that disguised it

• Only the arm64 leg runs any tests at all - every test step is gated on
  matrix.abi == 'arm64' - so the intel leg cannot go red and its green
  says nothing. That is the whole "always arm64" pattern.
• The baseline screenshot cache is only saved by a job that succeeds, so
  a failing pull request rebuilds the baseline on every run and keeps
  failing, while one green run makes later runs skip the baseline
  entirely and pass for the wrong reason.

Fix

#702 makes the suite say which view it needs rather than inherit it:
save PBShowStageView in -setUp, turn it off before the window is
built, and put the old value back in -tearDown.

Still open after that: the screenshot tests continue to leak the
preference into the shared domain, so any other suite that depends on
which view the window opens on stays exposed. Fixing that at source
belongs with the screenshot tests, alongside #700.