fix(cli): only name an installer that is actually there

[DeusData]

Fixes #1632.

update hands off to install.sh (install.ps1 on Windows) and prints the command to run. It built that command from cbm_detect_self_path — the binary's directory — and treated "I resolved my own location" as "the installer is beside me".

Those are different questions. install.sh is placed beside the binary by install.sh itself, so a binary that was moved, packaged by a distro, or built from source has no installer next to it. We printed the path anyway:

bash "/home/<user>/.local/bin/install.sh"
/usr/bin/bash: /home/<user>/.local/bin/install.sh: No such file or directory

Reported on discussion #1560 by a user who was already three releases deep in install trouble — and had just been told, by us, to run a file that does not exist.

update exists to tell someone how to proceed. Ending the interaction on a command that cannot run is the one outcome it must not produce. The fallback text was already present and already correct: it names install.sh as shipping in the release archive, without asserting a path.

Details

• The probe goes through cbm_path_info_utf8, so a non-ASCII install directory resolves on Windows.
• A directory named install.sh is rejected — bash <dir> is not a command either.
• A symlink still counts: it is reported rather than followed, and the shell runs it fine.
• The Windows branch gets the same treatment; it carried the identical assumption about install.ps1.

Verification — reproduce-first and revert-checked. With the probe forced to return true (the old behaviour), the new test fails with a directory with no installer must not be named as one; restoring it goes green. cli: 276 passed.