fix(control): a Retry button that could never work, reported through the widget

[catomean]

Filed from /control through the feedback widget — "what is this? can you fix?" — against an element reading:

focus_tab → fleetcrown failed: tab not found: fleetcrown … Retry

focus-failure.ts already exists to prevent this

Its own note argues a Retry beside "tab not found" is a lie: retrying re-issues an identical command against a target that is identically absent, so it fails identically, forever. It also predicts how the protection would break:

"a message and a classifier that each spell the same sentence independently are two definitions that drift the first time someone rewords the copy — and the drift is silent, since a misclassified failure still renders a plausible button."

That is exactly what happened, across a boundary the note did not consider. Two codebases word the same condition differently:

Path	Message	Classified
Cloud	no zellij tab with that name in any active session	✅ → Start session
Fleet Runner desktop (desktop/src/main/poller.ts:887,895)	tab not found: <name>	❌ → Retry

So focusing a project through a local Fleet Runner fell through to RETRY and drew a button that could never succeed.

Fixed in the classifier, not only the desktop app

Deliberate: Fleet Runner is versioned and released independently, so every operator still on an older build would keep sending the old wording. A classifier that only understands the newest client is one that lies about older ones.

Tests

The reported string verbatim, including the trailing 4m agoOpen on ControlRetry the element picker captured — because that concatenated text is what actually reaches the function. Plus casing, precedence against NO_TERMINAL, and two near-misses (tab closed by user, could not find the window) that must stay retryable, so the new match cannot over-classify.

Proven by mutation: removing the new match fails the assertion.

npm run verify exits 0.