`worktree.remove` kills a working agent, even when its task holds a lease

[atqamz]

What happened?

luvus worktree remove removed a worktree whose Codex worker was mid-turn (sleep 120 in the foreground) and whose task held a path lease. It returned {"type":"ok"}, closed the workspace and killed the agent. The task stayed running with assignee: None. These were the only events:

2009 terminal.closed  {"pane_id":"7",…}
2010 lease.released   {"leases":["l6"],"pane":"7"}
2011 workspace.closed {"workspace":"4"}
2012 pane.closed      {"pane":"7"}   (sent twice)

I expected a refusal, as for a dirty tree (git_error "…use --force"). The orchestration guide says to use this command to clean up a finished worker, but nothing checks that it has finished, so any client that cleans up by path can lose a running worker's work.

Steps to reproduce

1. luvus workspace open <repo>, then luvus task add "busy" --paths notes/busy.txt --prompt "Run in the foreground and wait for it: sleep 120. Then mark the task done."
2. luvus task start t1 --agent "codex --dangerously-bypass-approvals-and-sandbox" --no-focus
3. Wait until luvus agent get <pane> shows working.
4. luvus worktree remove ~/.luvus/worktrees/<repo>/luvus-t1

Area

orchestration, workspaces, git and diff

Environment

• OS: Omarchy (Arch-based) Linux, kernel 7.2.5
• Luvus 0.14.2 (AUR luvus-bin), a named session driven over the CLI and UHP. luvus doctor: all checks pass.
• On main at 732c81c, finish_explicit_worktree_remove still closes the workspace without any check.

Anything else?

Proposal: refuse with something like worktree_in_use, listing the pane ids, when a pane whose cwd is inside the path has a working or blocked agent, or holds a lease. Add force: true (--force on the CLI) to keep today's behaviour.

Related: #389, #420

Related: #389, #420 (the sidebar deletion path). Client-side context: atqamz/hand#707 never calls worktree.remove; it removes worktrees itself after checking for a live worker and uncommitted changes.