afx spawn --resume recomputes worktree path from issue title, breaking when issues are renamed

[waleedkadous]

Bug

`afx spawn --resume` recomputes the worktree path from the current GitHub Issue title rather than using the stored path in `status.yaml`. If the issue title has changed since the builder was originally spawned, resume fails with "worktree does not exist" even though the worktree is right there.

Reproduction

1. Spawn a builder: `afx spawn 653 --protocol spir` → creates worktree `.builders/spir-653-better-handling-of-builders-th` from the then-current issue title
2. Rename the issue: `gh issue edit 653 --title "New title"`
3. Try to resume: `afx spawn 653 --resume`
4. afx computes a new worktree path from the new title (`.builders/spir-653-new-title`) and fails:
   `[error] Cannot resume: worktree does not exist at /path/spir-653-new-title`

Actual output from today

```
Resuming Builder builder-spir-653 (spir)
Branch: builder/spir-653-mid-protocol-checkpoint-prs-as
Worktree: /Users/mwk/Development/cluesmith/codev/.builders/spir-653-mid-protocol-checkpoint-prs-as
[error] Cannot resume: worktree does not exist at /Users/mwk/Development/cluesmith/codev/.builders/spir-653-mid-protocol-checkpoint-prs-as
```

The real worktree was at `.builders/spir-653-better-handling-of-builders-th` — computed from the original title before the rename.

Workaround

Rename the issue back to the original title, resume, then rename again later. Fragile.

Expected behavior

`--resume` should find the existing worktree regardless of issue title. Options:

1. Store worktree path in `status.yaml` when the project is first spawned, and read it back on resume. This is the cleanest fix — porch already owns `status.yaml` per project.
2. Glob `.builders/${protocol}-${id}-*` and pick the single match. Simpler but less robust (fails if multiple matches or the directory naming convention ever changes).
3. Check git worktree list for a branch matching `builder/${protocol}-${id}-*` and use its path. Most robust — git is the source of truth for worktree state.

Option 1 is probably right: store it in status.yaml at spawn time, trust it at resume time.

Why this matters

Issue titles get renamed — specs evolve, framings change, typos get fixed. The architect shouldn't have to remember to preserve the exact original title just because a builder exists for the issue. Today a harmless `gh issue edit` can silently break a long-running builder's resume path.

Related

Discovered today while trying to rename #653 and resume its builder after the Apr-4 spec rewrite. Had to revert the title change to resume successfully.