Read the remote by its name instead of assuming origin

[derjabkin]

Every fetch, push and remote-tracking ref was spelled origin literally, so a clone
whose remote is called anything else - git clone -o github, or an origin that was
renamed - failed on each of them. The failures were quiet: the start page caught them
and showed an empty branch list, or a list whose merged and ahead labels were silently
missing, and the reader had nothing to go on.

The remote is now resolved once per repository, in GitService.GetRemoteAsync:
checkout.defaultRemote first, because that is the reader saying so and git's own
setting for it; then origin, which is what a clone calls the place it came from; then
the only remote, if there is one; then the remote the checked-out branch tracks. git's
existing config is used rather than a switch of our own - a reader with several remotes
has usually already told git which is meant.

When none of that decides, the operation fails with a sentence that says how to choose,
instead of a git error about an unknown revision. A failed lookup is not cached, so the
next refresh sees a remote that has since been added or configured.

The start page now reads what is local - branches, stashes, worktrees - before anything
that needs the remote, so a clone that cannot name one still lists its branches, with
the reason above them; the reload path reports it too rather than swallowing it. Status
lines, menu items and tooltips no longer promise "origin" for a remote called something
else.

Tests cover the choosing order as a pure function, and a real clone whose remote is
called github: fetch, default base and push all go to it, and both refusals - no
remote, and several with nothing to choose by - are asserted on their messages.