cdd-worktree-done calls adapters from the feature worktree after removing it #124

Problem

cdd-worktree-done resolves the code-host adapter from the feature worktree ($top/.cdd/code-host, e.g. ~/Code/cdd-<branch>/.cdd/code-host), then removes that worktree (step 1), and only afterwards calls cdd-worktree-merged-pr (step 2) through the now-deleted path. The call fails (exit 127), is treated as "could not answer" (prc=2), and:

1. A squash-merged branch falls to the [d]elete (-D) / [k]eep / [a]bort? prompt even though its PR is merged and nothing needs attention.
2. On d, the branch is deleted but pr_unknown=1; a task with issue_refs then sets keep_for_gc=1, so the handoff, plan, state record and refs/cdd/<branch> are all kept — the task stays listed (e.g. in cdd-dash) until cdd-worktree-gc --force.

The tracker adapter has the same flaw: cdd-worktree-resolve-tracker runs before the cd, from the feature worktree, and cdd-worktree-close-issues uses it after the removal.

Regression from the in-repo .cdd/* bindings (#117) combined with dropping the built-in gh fallback rung (#119, ADR 0012): before, the fallback still answered. Still present on main after #122/#123.

Repro

In a repo bound via .cdd/code-host, on a feature branch whose PR was squash-merged and whose state record has issue_refs: run cdd-worktree-done from the feature worktree. Observed: warning: pr-merged failed (exit 127) via …/.cdd/code-host …, the d/k/a prompt, and the handoff/state kept. Seen on #122 and #123 here.

Suggested fix

Ask the code host whether the PR merged (and capture the tip) before git worktree remove — deciding before destroying anything is also the safer order. Resolve the tracker adapter (or re-resolve both) from $main_path, or anywhere that survives the removal, so the issue close works afterwards. Add a test covering an adapter binding that lives inside the feature worktree.