fix(remove): continue after per-target execution failures

[max-sixty]

A pre-remove hook or synchronous Git failure in one target currently stops a multi-target removal before later targets are attempted. Continue with the remaining valid targets, report each ordinary failure, and return exit status 1 if any target failed. JSON includes successful targets in execution order, including branch-only removal and the current worktree executed last.

SIGINT and SIGTERM cancel the batch immediately with exit status 130 or 143. Preserve the underlying error in foreground removal diagnostics so a captured Git interruption reaches the batch cancellation check.

Validation: 5,068 tests passed (one skipped), doctests and documentation build passed, and all final pre-commit checks passed. Integration coverage exercises hook and execution-time removal failures in foreground/background modes, correct JSON attribution, and hook/Git interruptions, including a detached checkout. Four Git-interruption regressions fail against the original executable and pass with this change; independent review found no remaining issues. Help and generated documentation checks passed after updating from main.

This was written by Codex on behalf of max-sixty

[worktrunk-bot]

This changes what wt remove a b c deletes after a failure. Before, a pre-remove hook failure or a Git failure on a stopped the batch, so b and c (and the current worktree, which runs last) were kept. Now those later targets are removed. Each target still has its own validation, pre-remove hook, and Git dirty check, and the user named every target, so this looks intended. But it widens when worktrunk deletes, so under the repo's data-loss hold (.claude/skills/running-tend/references/review-pr.md) the merge decision stays with @max-sixty and this review doesn't approve it.