spawn_task should auto-add .claude/worktrees/ to .git/info/exclude in version-controlled repos

When spawn_task (or the broader Claude Code worktree mechanism) creates a worktree at .claude/worktrees/<name> inside a directory that is under git version control, the worktree directory shows up as an untracked submodule-shaped entry in git status and git add -A warnings. This appears to surprise every user the first time they hit it, and the natural fix — adding .claude/worktrees/ (or .claude/) to the committed .gitignore — is the wrong fix:

• git worktree add refuses to operate inside an ignored path. Committing the rule breaks the worktree mechanism for everyone who clones the repo, not just the user who added the rule.
• The trap is recursive: a Claude Code session running git add -A sees the warning, "fixes" it by editing .gitignore, the user merges, and the next clone of the repo can no longer use spawn_task.
• I've had this happen across at least four sessions. I assumed it would have been auto-resolved by now in an update. It hasn't been.

The right local fix is .git/info/exclude — same syntax as .gitignore, but lives inside .git/ and is never committed. Each clone has its own ignore list.

Suggested fix

When spawn_task (or whatever orchestrates git worktree add) creates a worktree inside a git-tracked repo, it should detect that and append .claude/worktrees/ to .git/info/exclude (idempotently — only if the line isn't already there). That way:

• The worktree directory stops showing as untracked locally.
• No committed file is touched.
• git worktree add continues to work because the ignore is local-only.
• Users (and Claude sessions) stop reaching for the wrong .gitignore fix.

Repro

1. cd into any git-tracked repo.
2. Trigger a spawn_task chip (creates a worktree at .claude/worktrees/<name>).
3. Run git status or git add -A — observe the embedded-submodule warning.
4. The natural "add to .gitignore" fix breaks git worktree add going forward for the repo.