repo sync: detect self-merged stacks pushed directly to trunk

[ed-irl-codebot]

Problem

gs repo sync loses track of stacks that were "merged" by force-pushing
the stack tip directly to trunk on the remote. Supported forges (GitHub,
GitLab) don't report the underlying change requests as merged in that
case, so the stack stays tracked with a stale BaseHash; subsequent
restacks replay against the new trunk and cause conflicts.

The pattern is common: finish a stack locally, skip the PR-merge ritual,
force-push the tip to main. The forge sees a normal push and reports
no merged CRs, so sync leaves the stack tracked and every later
operation has to re-discover the merge by hand.

Proposal

Run the same local-ancestor merge check the unsupported-forge path
already uses, on the supported-forge path too, after the forge API
queries return. Any tracked branch whose head is reachable from the new
trunk hash is treated as merged, regardless of what the forge reports.

• Branches with submitted CRs still attach their ChangeID for downstack
  history propagation.
• Unsubmitted branches log merged into trunk locally for a paper
  trail.
• Branches not reachable from the new trunk are left tracked (no
  false-positive cleanup).

This makes sync behavior consistent across supported and unsupported
forges.

Tracked by

• feat: add worktree management commands, per-worktree trunks, and worktree-aware filtering #1221 — detect self-merged stacks pushed directly to trunk