feat: Surface post-checkout hook output during worktree creation

[chuks-qua]

What

When t3code creates a git worktree, git automatically runs post-checkout hooks. Today that output is invisible to the user. This proposal adds visibility into hook execution and improves the existing setup script system.

Why

Teams can use post-checkout hooks for dependency installation, env file copying, and codegen. When these run silently during worktree creation, users can't tell whether setup succeeded or failed. Failed hooks lead to broken worktrees and wasted time debugging phantom issues.

t3code already has a "setup script" system (project actions with runOnWorktreeCreate), but post-checkout hooks are a native git feature that can be version-controlled via .githooks/ + core.hooksPath.

Proposal

1. Capture and display post-checkout hook output in the thread UI

GitCore.createWorktree already calls executeGit, which returns { code, stdout, stderr }. Hook output flows through these streams. Today the result is discarded (only path and branch are returned). The change: include stdout/stderr in GitCreateWorktreeResult and render them in the thread UI alongside existing setup script output.

2. Handle hook failures gracefully

If a post-checkout hook exits non-zero, git worktree add itself fails. The current code treats this as a GitCommandError with stderr. Surface this as a clear warning in the thread before the first message, so users know their worktree may be in a broken state.

3. Auto-detect and suggest setup for unconfigured projects

When a project has no post-checkout hook and no setup script configured, detect common lockfiles (bun.lock, package-lock.json, yarn.lock) and suggest creating either:

• A post-checkout hook (version-controlled, shared with the team)
• A t3code setup script action (per-user, configured in the UI)

Implementation notes

• The data flow (git process -> GitService.execute -> GitCore.createWorktree -> IPC -> thread UI) already passes structured results at every layer. This is additive: extend the return type and render the output.
• post-checkout hooks receive three arguments: previous HEAD, new HEAD, and a flag (1 for branch checkout). Worktree creation passes 1.
• Hooks must be non-interactive. Hooks that prompt for user input will hang because the child process has no TTY. This is standard for automated environments but worth documenting.
• The existing single-setup-script constraint seems sufficient. Users who need multiple steps can combine them in one command or use a post-checkout hook.