WorktreeCreate/WorktreeRemove hook gating and fallback behavior refined

What

• In the worktree-create flow, if no hook commands ran at all, the code used to always throw a "hook is configured but did not run" error. Now it first checks whether any WorktreeCreate hook is actually configured, and silently continues if none is, only throwing when a hook is genuinely configured but failed to run.
• The decision of whether to use a WorktreeCreate hook (instead of falling back to the built-in git worktree flow) now goes through a renamed gate that checks either an existing predicate or the presence of a registered WorktreeCreate hook.
• The existing WorktreeCreate/WorktreeRemove hook events are now also checked through a broader capability lookup (not just whether hooks are registered for them), used to decide whether the worktree create/remove UI is shown at all.

Why These changes reduce spurious "hook is configured but did not run" errors when no worktree hook is set up, and make the logic for whether worktree create/remove hooks and UI are active more consistent.