mr fetch can resolve a branch member to a stale commit unless --force is passed

Split out of #962, which is now scoped to the mr apply half (fixed in #963).

Problem

mr fetch can resolve a #<branch> member to a stale commit and only pick up the true remote
tip when passed --force.

Observed repeatedly in one session: mr fetch --apply resolved effect-utils#main to
b5e983b0 while GitHub's main was many commits ahead. mr fetch --force then resolved the
true tip. This happened across several repos, so it is not a single corrupted mirror.

A likely-related observation, unverified as the same cause: a canonical store worktree for
main sat at a commit that was not an ancestor of origin/main (f7215007d vs
2dcbfd8e1), i.e. the local mirror had diverged rather than simply lagged.

Why it matters

The lock is meant to record the resolved tip of the configured ref. If resolution reads a stale
mirror, mr fetch writes a lock entry that does not correspond to the remote ref it names, and
every downstream consumer inherits it — silently, because the lock looks perfectly well-formed.

Expected

mr fetch resolves a branch member to the current remote tip without needing --force, or
reports why it cannot.

Notes

Unlike the apply-side defect, this one writes the lock rather than the workspace, so the
mr apply drift guard added in #963 will not catch it — a stale-but-consistent lock and
workspace agree with each other.

Start by tracing the mr fetch branch-member resolution path and how it writes the lock, then reproduce the stale result with and without --force across the affected repositories. Check how the canonical store worktree and remote tip are consulted. Done means mr fetch resolves the configured branch to the current remote tip without --force, or reports why it cannot.