fix(worktrees): ownership check is forgeable by directory name and lock-reason prefix

[euxaristia]

Summary

verifyZeroOwnedWorktree in internal/worktrees/worktrees.go proves a worktree is Zero-owned using two signals that a user can reproduce by hand: a predictable zero-worktree-<repoKey> ancestor directory name, and a lock reason starting with the zero: active task worktree prefix. A worktree created under that directory and manually locked with a matching reason passes the ownership check, so zero worktrees release will clear that lock, and a subsequent zero worktrees clean can then force-remove the checkout.

Raised by jatmn's review on PR #632 (#632 (comment)); not fixed there because it needs a migration decision first (see below).

Affected code

• internal/worktrees/worktrees.go (verifyZeroOwnedWorktree, the strings.HasPrefix(entry.lockReason, leaseReasonPrefix) check)

Current behavior

Ownership is inferred entirely from a directory-name convention and a lock-reason string prefix, both fully known and reproducible by anyone reading the source or the lock reason on an existing Zero worktree.

Expected behavior

release and clean should only be able to act on worktrees Zero itself created, verified through something a user can't trivially reproduce by hand.

Why this wasn't just fixed alongside the other findings

internal/worktrees has been on main since #70, well before the PR that raised this. Any fix that makes a new ownership marker mandatory risks rejecting worktrees an already-installed zero created before the marker existed, breaking release/clean for them on upgrade. This needs a migration story, not just the check itself.

Suggested implementation

• Write a durable ownership marker when Prepare creates a worktree, e.g. a file inside the worktree's own git administrative directory (not the visible working tree, so git worktree remove cleans it up automatically and it never appears as an untracked file).
• Decide the migration path for worktrees created before the marker existed: a grace period that accepts the current prefix-only check with a deprecation warning, a versioned marker, or similar. Don't make the marker mandatory on day one.
• Update verifyZeroOwnedWorktree to check the marker once the migration window has been decided.

Suggested tests

• A worktree with a valid marker releases successfully.
• A worktree under the predictable directory with only a matching lock-reason prefix but no marker is handled per whatever migration behavior is chosen (accepted with warning, or rejected, depending on the decision above).
• A worktree with a mismatched/corrupted marker is rejected.

[Vasanthdev2004]

I went looking to confirm this and could not, because none of the code it describes is on main.

Checked directly:

• internal/worktrees/worktrees.go exports only Prepare and DefaultBaseDir. There is no verifyZeroOwnedWorktree anywhere in the tree.
• No leaseReasonPrefix, no lease or lock concept, and Prepare never runs git worktree lock. A repository-wide search for verifyZeroOwnedWorktree|leaseReasonPrefix|worktree lock|zeroOwnerMarker returns nothing.
• The zero-worktree-<repoKey> directory name does exist (worktrees.go:87), but nothing on main ever reads it back as an ownership signal, so there is nothing for a forged name to fool.

The reasoning in the report is sound, it just applies to the ownership check in #632, which has not merged. So there is no exploitable path on main today, and the fix belongs in that PR rather than in a separate issue against shipped code.

I would rather fold this into #632's review than track it twice, so I am proposing to close as a duplicate of #632. Say if you would prefer it stay open as the tracking issue for that specific weakness and I will leave it, since the underlying point is worth not losing when #632 gets another pass.

[Vasanthdev2004]

Closing as a duplicate of #632, where the code this describes actually lives. Nothing on main performs the ownership check, so there is no exploitable path against shipped code today.

To be clear this is a filing decision, not a dismissal of the finding. The weakness is real for #632 and I would rather it be raised in that review than tracked against code that has not merged. Reopen if you would prefer it stand alone as the tracker, or if #632 lands without addressing it.