Removing a hard-coded environment-module fallback from remote launcher scripts silently disables the tool on hosts where bash -l does not put it on PATH

Context: launcher scripts run over ssh under bash -l used to do module load <site module> when the tool was not on PATH. Replacing that with PATH, then $TOOL_HOME/bin, then a user-set setup command (e.g. CMUX_TOOL_SETUP="module load x") is the right call for a public repo, but check before shipping: (1) run ssh host bash -lc "command -v tool; type module" on the real target. On a typical HPC/EDA host the module function exists but nothing is loaded in a login shell, so after the change every launch reports not-found. (2) bash -l reads ~/.bash_profile or ~/.profile, not ~/.bashrc unless sourced, so tell users which file to set the variable in. (3) Make sure the UI string for the not-found error names the variables to set. A localized message like "not installed on the host" hides the launcher hint and sends users the wrong way. (4) Put a time cap on the eval of the user setup command (module locks can hang). Also: when a review is asked whether an earlier review covers some commits, compare patch-ids (git show C | git patch-id --stable) and check whether the commits lie in the reviewed range (git rev-list A..B), because a follow-up fix with the same subject prefix is often a different change.