Warn before a safe delete git will refuse

A branch with no upstream was deleted with -d and failed at run time with
nothing having warned about it. Every safety indicator derived from the
ahead count, which git leaves at 0 for such a branch because it reports
no tracking info for one.

safeDeletable() now mirrors git's actual rule: a resolvable upstream is
the sole criterion, and HEAD is consulted only when there is no upstream
to ask. This is a precedence rather than an either-or -- git refuses a
branch that is ahead of its upstream even when HEAD already contains it.
Every branch the rule would refuse is measured with `git cherry`, so the
confirm screen states what a force delete would discard.

Also:
- the force prompt reports the measured count instead of the ahead
  count, which was 0 for exactly the branches reaching it without an
  upstream, leaving the prompt with nothing to show
- an armed remote delete is deferred when the local delete is refused,
  rather than removing the last copy of commits that still exist only
  locally; a successful force retry then honours the arming
- only an "not fully merged" refusal is offered as force-retryable. A
  branch held by another worktree fails identically under -D, so the
  retry could not have worked and mislabelled the cause. runGit pins
  LC_ALL=C so gettext cannot translate the string out from under it
- risk is measured lazily for the current selection. Measuring every
  unmergeable branch on load cost 1.1s of startup on a 61-branch repo;
  gone branches stay eager, since `p` consults the count to decide what
  it may auto-select

Tests cover each shape that decides the outcome, checking safeDeletable
against what `git branch -d` really does rather than against an
assumption about it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: skunkworker