[Fix] Derive worktree name from -b when no name given

[samzong]

What's changed?

• gmc wt add -b <branch> now works without a positional argument; the worktree name defaults to the base-branch value. When the branch already exists, this checks it out directly (existing addArgs logic).
• Split the -b/--base flag variable between wt add and wt dup. They previously shared wtBaseBranch, and dup's "main" default overwrote the variable at init time, so wt add's -b effectively defaulted to main.
• Updated wt add's Use / Long / Example to reflect the new optional-name form.

Why

Smoother ergonomics for the common case of creating a worktree from an already-named branch (e.g. PR review, agent-dispatched work): gmc wt add -b feat/foo reads naturally without repeating the name. Also removes a latent init-order bug where wt add's base default was not actually "".

Repro of the original error

$ gmc wt add -b feat/gateway-doctor-memory-rem-harness
Error: requires at least 1 arg(s), only received 0

After this change, the command succeeds and creates a worktree named feat/gateway-doctor-memory-rem-harness (directory: feat--gateway-doctor-memory-rem-harness, per existing dir-name rule).

Considered and deferred

• cmd/worktree.go [BOT-NIT]: wtBaseBranch could be renamed to wtAddBase for symmetry with wtDupBase / wtPruneBase. Deferred — not a behavior concern.
• cmd/worktree.go [BOT-SCOPE]: No cmd-level test for the new zero-arg + -b path. Deferred for a follow-up test-only PR.

[gemini-code-assist]

Code Review

This pull request updates the worktree add command to allow the worktree name to be derived from the base branch when no positional arguments are provided. It also introduces a separate wtDupBase variable for the dup command's base branch flag and includes several minor refactorings, such as simplifying execCommand assignments and improving error handling consistency. I have no feedback to provide.