Enhance: [Worktrees] offer to repair linked worktrees after the main repository's folder moves #739

Split out of #675, whose slice 5 (#731) repairs a linked worktree whose own folder was moved. The opposite case, the main repository's folder moving, was left out.

What happens

Each linked worktree's .git file holds an absolute path to <main>/.git/worktrees/<id>. Once the main folder is moved or renamed, that path is stale:

• From the moved main repository, git worktree list --porcelain still lists the linked worktree with its HEAD and branch, and not as prunable. So the WORKTREES group shows it as healthy.
• Inside the linked worktree, every git command fails with fatal: not a git repository: <old main>/.git/worktrees/<id>.
• git worktree repair with no path, run in the main worktree, rewrites the broken .git files. It prints repair: .git file broken: <path> for each one and exits 0.

Checked with git 2.50.1 (Apple Git-155).

Why an automatic repair and not a menu action

Git documents a single fix for this case, git worktree repair from the main worktree, and it only touches links that are already broken. Unlike #731, the user has nothing to choose. Tower documents repair only for a moved worktree folder, and Fork and GitKraken document none. So GitX should repair on its own, with the user approving the change first because it writes into folders outside this repository.

Proposal

1. Detect it on refs reload by reading each linked worktree's .git file and comparing its gitdir: with this repository's worktrees/<id> folder. The porcelain alone cannot show it.

2. Ask once with a sheet on the repository window, listing the worktrees whose link is broken:

   This repository was moved, so N of its worktrees can no longer find it:
     <path>  (branch)
     ...
   GitX can reconnect them with "git worktree repair".
                                          [Cancel]  [Repair]
   

3. On Repair, run git worktree repair and reload the worktree list. If git reports an error, show it and treat the result the same as Cancel.

4. On git before 2.29, which has no repair, the sheet only states the situation. It lists the same worktrees, names the git version found and the 2.29 needed, suggests upgrading git (or pointing GitX at a newer one in Preferences, where the git path is set), and has a single OK button. The rows are marked as below, and Repair Worktree Links is shown disabled with a tooltip naming both versions.

Git before 2.7 needs no handling: it has no worktree list --porcelain, so the WORKTREES group is empty and nothing is detected.

If the user cancels

The main repository works normally after the move; only the linked worktrees are broken, so Cancel must not block this window. GitX continues and marks the broken worktrees:

• The rows are dimmed like a missing folder, with a tooltip saying the link to this repository is broken.
• The row menu offers Repair Worktree Links, which runs the same repair.
• Open Worktree on such a row shows git's error and offers the repair again.
• Cancel (or OK on an older git) is not remembered: the sheet comes back each time the repository is opened while any link is still broken. This stays accurate when the user repairs from the command line instead.

Rejected alternatives: letting git fail with its raw not a git repository error, which names a path that no longer exists and does not say how to fix it; and closing the window or quitting, which refuses to show a repository that works over a problem in other folders.

Out of scope

• Opening a broken linked worktree directly (File > Open on its folder). GitX then has no way to find the main repository, since the path it knows is stale. It could offer to locate the main repository and run the repair from there, but that is a separate flow.
• Relative worktree links: worktrees created with worktree.useRelativePaths (git 2.48) should not break this way, since their links do not hold absolute paths. Not verified.