fm-control.sh relaunch refuses when the recorded herdr workspace has fully vanished, citing a stale wrong endpoint #6

Problem

bin/fm-control.sh <task-id> relaunch refuses to relaunch a dead scout task,
consistently, across two separate attempts, with:

error: task <id>'s endpoint is in '<PROJECT_CLONE_PATH>', not its recorded
worktree '<TREEHOUSE_WORKTREE_PATH>'; refusing to relaunch an agent outside
the copy holding its work

The cited "endpoint" path is the home's plain project clone
(projects/<project>), not anywhere the dead task's recorded window
(state/<id>.meta's window=, herdr_workspace_id=, herdr_tab_id=,
herdr_pane_id=) ever pointed.

Live-checked at the time of both failures:

• herdr workspace get "<recorded workspace id>" -> workspace_not_found
  (the whole recorded workspace is gone, not just the tab or agent).
• herdr agent list -> exactly ONE live agent existed in the whole herdr
  session at the time (the calling firstmate primary itself, cwd
  ~/firstmate). Nothing was running at the cited
  projects/<project> path.
• The actual worktree the task's meta records
  (~/.treehouse/<repo>-<hash>/<n>/<repo>) was confirmed intact and properly
  held (treehouse status from inside it reports "you're here", not
  "available").

So the cited endpoint is neither the recorded target nor anything live -
some fallback path in the endpoint-detection logic appears to resolve to a
stale or wrong value once the recorded herdr workspace has fully
disappeared (as opposed to merely having its agent exit while the
workspace/tab still exist), rather than reporting "no live endpoint, safe to
relaunch fresh into the recorded worktree."

Reproduction

1. Have a kind=scout task recorded against a herdr backend
   (window=<session>:<workspace>:<pane> in its .meta).
2. Let the entire herdr workspace for that task disappear (not just the
   agent exiting - the workspace itself no longer resolves via
   herdr workspace get).
3. Run bin/fm-control.sh <task-id> relaunch --note-file <path>.
4. Observe the refusal above, citing an unrelated existing project clone
   path as "the endpoint," even though nothing is running there.

Impact

The task's own work is safe (confirmed - relaunch never touches the
worktree on this failure path, it just refuses to launch a replacement),
but the task is stuck with no live worker and no way to resume it through
the sanctioned recovery path (stuck-crewmate-recovery skill -> fm-control.sh relaunch), forcing either manual herdr surgery (which the skill explicitly
warns against) or leaving the task dead until a human intervenes.

Suspected area

bin/fm-control.sh's relaunch endpoint-resolution step - whatever it falls
back to when the recorded herdr workspace/tab/pane cannot be found at all
(full absence, not just an exited agent inside a still-existing pane).