fix(queue): make remote dispatch possible and probe with a login shell

[LeTuR]

Dispatching to debian-hp — registered in hosts.toml, reachable, all three probes green — could not spawn a worker, and the probes lied about why. Two independent defects.

--parent made every remote dispatch impossible

dispatch passed --parent $THURBOX_SESSION unconditionally. thurbox validates a parent against the host's own backend and refuses one that lives anywhere else:

spawn failed: parent session '📡 Mission Control' runs on local-tmux, not on
host 'debian-hp'; a session's parent must be on the same host

The lead is local by construction, so the flag could only ever fail — after the three --host probes had already run and passed on a flag that had nothing to do with them.

thurbox offers no way to express "child of a session on another host." spawn_delegated (src/session_ops/spawn.rs:519) compares parent.backend_type against the host's backend name and errors on any mismatch; there is no cross-host form of the field. So omitting it is the whole fix. A local spawn still gets its parent — that half is asserted too, so the link is not quietly dropped for everyone.

Probes ran in a shell that could not see the host's binaries

ssh host 'cmd' gets a shell that is neither login nor interactive. No profile runs, so PATH is the bare system default — while agent and thurbox binaries live in ~/.local/bin, which is exactly what the profile puts there. The forge probe's command -v gh / command -v glab therefore answered "not installed" about a machine that has both, and the lead read that as an unprovisioned host.

Measured on debian-hp, whose login shell is zsh:

shell	command -v thurbox-cli
bare ssh debian-hp	not found
zsh -lc	not found — a non-interactive zsh reads no ~/.zshrc
/bin/sh -lc	/home/thurbox/.local/bin/thurbox-cli

So /bin/sh -lc is both the simpler answer and the better one, and it is thurbox's own remedy for the same bug (#1100's login_wrap_for_remote). Nothing hard-codes zsh; BatchMode and ConnectTimeout are untouched.

The two calls that only move bytes stay on a bare shell. The brief push and the result fetch need no binary beyond cat, and a profile that prints a banner would land it in the middle of a fetched result.md. One rule: a login shell to find something, a bare one to carry something.

A wrong answer no longer reads as a missing host

• A probe after the first that dies on ssh's reserved 255 is reported as the connection going away, not as the question being answered no.
• The forge probe now says which forge CLIs it found: "gh is installed there and not logged in" and "neither gh nor glab is on its login shell's PATH" are different problems, and the second is what the non-login PATH used to manufacture. Both open with "the host ANSWERED".
• Probe output is read off the last line of stdout, so a chatty profile cannot garble it.

Verified

A test per defect in scripts/queue-selftest.sh §11, each failing on the parent commit for its own reason (--parent present in the logged session create; rc=1 from command -v). The login-shell test is a real shell against a fake home whose .profile adds a ~/.local/bin and also prints — no second machine, and the banner test is what pins the byte-moving half.

Live against debian-hp, through fleet's own ssh_run:

'command -v thurbox-cli'  rc=0  '/home/thurbox/.local/bin/thurbox-cli'
'thurbox-cli --version'   rc=0  'thurbox-cli 2.20.0'
'command -v gh'           rc=0  '/home/thurbox/.local/bin/gh'

./scripts/check.sh green.

Scope held to the POSIX remote path: no psmux/Windows support, and the probes ask exactly what they asked before.

https://claude.ai/code/session_018PX64cpUAiMSuGv2idn6Cx