fix(branch): Reject unresolved explicit anchors

[reneleonhardt]

fix(branch): Reject unresolved explicit anchors

🧢 Changes

• Reject an explicit but branch new --anchor <value> that cannot be resolved
  in the current workspace.
• Keep default-base selection exclusive to calls that omit --anchor.
• Cover a fetched merge anchor and verify rejection before creating a branch
  ref.

☕️ Reasoning

An explicit anchor is a requested history boundary, not a hint. Omitting one
and supplying one that cannot be resolved are distinct operations.

The invariant is independent of selector syntax: future change-ID or worktree
graph improvements may make more anchors resolvable, but an unresolved explicit
anchor must never fall back to the workspace base. Failing before mutation
keeps the repository recoverable and prevents agentic coding from replaying
history onto a boundary it did not request.

🧪 Reproduction

cargo test -p but rejects_fetched_merge_anchor_outside_workspace_before_replay

Before this fix, the explicit fetched merge anchor was treated as absent, so
branch creation succeeded at the workspace common base and a later replay could
synthesize widespread conflicts.

✅ Verification

• The fetched-merge regression fails on the old fallback and verifies that no
  reconstruction ref is created.
• All 10 branch-creation tests and the GitHub Rust/Tauri/Windows/E2E checks
  passed.

Developed with carefully directed, manually reviewed AI assistance.

Co-Authored-By: GPT-5.6 Sol codex@openai.com

[Byron]

Thanks a lot for the minimal fix and the tests.

As the source change is so minimal, I think @slarse would be able to take a look and see if the PR has merit, especially in the face of a possibly planned 'branch2'.