Worktree removal now checks for uncommitted submodule work

What

• Removing a git worktree (for example via the claude rm or ctrl+x flow, or automatic agent-worktree/job cleanup) now checks for work inside submodules, not just the top-level worktree. A new submoduleWork concept distinguishes "unverifiable" submodule state (such as a nested repo or an unconfigured gitlink) from ordinary uncommitted "changes" inside a submodule.
• When submodule work is unverifiable or has changes, worktree removal now refuses to proceed and shows a message naming the issue explicitly, with tailored explanatory text and follow-up instructions for each case; job deletion can likewise keep a worktree around for this reason.
• The confirmation dialog shown before discarding uncommitted changes in a worktree now separately calls out submodule work that a plain git status in the worktree wouldn't reveal.
• Before counting changes, the "exit worktree" confirmation dialog now also checks the worktree's git configuration for unsafe settings (such as conditional includes or custom LFS transfer agents); if the worktree can't be safely read, it shows a generic "uncommitted files that could not be counted" warning instead of a count, and checks submodules via a --submodule=short diff, adding a warning line if a submodule can't be checked.
• The JSON snapshot of git worktree state sent over the remote bridge now includes a submodules_unverified field alongside existing fields like head_sha, unpushed_count, and is_dirty.

Why Submodule changes don't always show up in a normal git status of the parent worktree, so without these checks a worktree could be deleted while it still held uncommitted or unverifiable work inside a submodule. This makes worktree removal safer and more transparent about what it could and couldn't verify.