feat: add worktree visibility and safe deletion

[ashproto]

Summary

• show repository worktrees in a dedicated sidebar panel
• mark local branches that are checked out in a worktree and expose the worktree path
• offer guarded branch-and-worktree deletion with explicit opt-in and safety checks
• cover worktree parsing, deletion safeguards, dialogs, and UI behavior with tests

Validation

• cargo test -p git-core -p git-it
• cargo clippy -p git-core -p git-it -- -D warnings
• npm test
• npm run check
• npm run build
• git diff --check

[chatgpt-codex-connector]

💡 Codex Review

git-it/crates/git-core/src/ops.rs

Lines 363 to 367 in 4a0cfec

	let oid = exact_ref_oid(repo, upstream_ref).map_err(|_| {
	format!(
	"The upstream for branch '{branch}' is unavailable, so safe deletion could not be verified. Fetch or use Force delete."
	)
	})?;

Fall back to HEAD when the upstream ref is gone

When a linked-worktree branch still has tracking configuration but its remote-tracking ref was deleted—common after a merged PR auto-deletes its branch—%(upstream) still returns that now-missing ref, so this path rejects deletion even if the branch is fully merged into HEAD. Checked with Git 2.43: git branch -h defines -d as “delete fully merged branch,” and git branch -d successfully deletes this exact merged/gone-upstream case. Treat an unresolved upstream as absent and use the HEAD baseline rather than forcing the user to select Force delete.

---

git-it/src/lib/gitActions.ts

Line 323 in 4a0cfec

try { await refreshRefs(); } catch (err) { console.warn("[gte] refs refresh after failed op", err); }

Refresh graph decorations after a partial branch delete

When local deletion succeeds but the optional remote deletion fails, this refresh does not actually remove the branch from the sidebar: refsByKind overlays graphCommits[*].refs after refsDetailed in store.svelte.ts:748-763, so the stale graph decoration re-adds the deleted local branch. This also affects the new combined worktree/branch/remote flow, leaving a removed worktree paired with a selectable branch that no longer exists. Refresh or selectively update the graph decorations while preserving queued edits.

---

git-it/crates/git-core/src/ops.rs

Lines 577 to 581 in 4a0cfec

	if status.staged > 0
	|| status.unstaged > 0
	|| status.untracked > 0
	|| status.conflicted > 0
	|| status.operation.is_some()

Block worktree removal during an active bisect

A clean linked worktree immediately after git bisect start still has its branch checked out, but status.operation is null because graph::detect_operation only recognizes merge, rebase, cherry-pick, and revert. The removal therefore proceeds and deletes the worktree together with its BISECT_* state. Checked with Git 2.43; git worktree remove -h only promises dirty/locked protection, so Git itself accepts this clean bisect worktree. Detect bisect state before offering or executing removal.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[ashproto]

Addressed all three Codex findings in 601d070:

• Gone upstream refs now fall back to HEAD for safe deletion, while prepared update-ref verification prevents either the HEAD baseline or the missing upstream state from changing under the delete.
• Partial local-delete success now refreshes graph decorations without discarding focus, selection, or queued edits. Detailed ref snapshots are empty-safe and repo-scoped, and graph refreshes are ordered against pagination, watcher events, and full reloads.
• Active bisect state is detected in linked worktrees and rechecked immediately before removal, preserving the worktree and branch.

Validation: 175 git-core tests and 7 git-it Rust tests passed; clippy passed with warnings denied; 313 frontend tests passed; svelte-check reported 0 errors and 0 warnings; production build passed. The original feedback was posted as one ordinary PR comment, so there are no review threads to mark resolved.