fix(worktree): include local branches in base ref options

[onevclaw]

Summary

• include both local branch refs and upstream refs when building worktree base-ref options
• keep deduplication and sorting behavior unchanged
• restore local branch selection for tracking branches (previously only upstream refs were surfaced)

Why this matters

When a local branch tracks origin/*, branchRefs(for:) currently returns only the upstream ref and drops the local one. This makes the base-ref picker look remote-only in cases where local and origin refs diverge.

Change

parseLocalRefsWithUpstream now emits both refs (local + upstream when present), then existing filtering/sorting/deduplication continues to apply.

Validation

• added/updated tests in GitClientBranchRefsTests to verify local + upstream refs are both returned

This is a contribution from downstream fork fix: onevcat#167.

[onevclaw]

Thanks for reviewing this.

After discussing this in our downstream repo, we realized this might not be an accidental miss, but an intentional design choice in upstream history:

• 7f454c88 (Add repo setting for worktree base ref): listed refs/heads + refs/remotes
• 594b7fd8 (Use local branches with upstreams): switched to refs/heads and mapped tracking locals to upstream refs
• 99a535ce (Test branch ref resolution): test expectations explicitly prefer upstream refs for tracking branches
• 062eb6fb (Add fetch remote branch before worktree creation): reinforces the "remote freshness" direction

So I think the current behavior is likely a product decision (canonicalizing tracking branches to upstream refs), not just an implementation bug.

My motivation for this PR is the local/remote divergence case: when local tip and origin/* differ, users may want to intentionally create a worktree from the local tip.

Question for maintainers: would you prefer to keep the current canonical upstream-only behavior, or accept exposing both local + upstream refs (with dedup/sort) so users can choose explicitly when they diverge?

I am happy to adjust the implementation (or close this PR) based on your preferred product semantics.

[sbertix]

Hey 👋 I can’t speak for @khoi, but I think there’s definitely value in presenting a more complete list of branches. I’d probably separate them from the main list, though. Something like origin Remote below, I was exploring for showing remote branches, but labelled Local, for instance. Wdyt? @onevclaw

[khoi]

I think including the local branches make sense, I removed it because the list get too long with a lot of duplicated branches on both remote/local.

I don't have an UI solution to solve this, I trust @sbertix on coming up with a decent UX for this. but I'm +1 for showing the comprehensive list