Drush 9.2 - not working well / not installing with Composer
Thanks for the replies. Managed to get things working:


I created a new folder (drushtest), and ran composer init to create a drush-only project (myname/drush). Init runs an interactive series of question to create a valid composer.json (with only require: drush/drush [and a version constraint]).
Ran Composer to install, and it pulled down Drush and its dependencies.
Then went to remote server, and copied to /vendor/bin, the two drush files, and to /vendor, the various folders that were in my Drush-only install versus what was already on the remote folder.
Deleted the existing composer.lock. In require section of composer.json, added drush/drush: ^9.2 [with appropriate quote marks], and ran composer update. Which worked fine. [I still don't understand the effect of .lock on .json, but I guess we're all learning in the new Drupal 8 way.]
To keep things still simple, went to my Drupal folder (web), and (per Drush docs) ran Drush: "../vendor/bin/drush" -- the first time this generated a shell error re no permission. So ran that again under sudo, and got a no command error. Third time lucky, applied "chmod u+x" to that path-file, and Drush sprang to life, and even identified the correct Drupal installation (with all associated info that one expects when Drush is working) without an alias file. Hurrah!
More on file permissions: for ../vendor/bin/drush, added the x flag to the group (permissions are now 754), and can run that command without sudo (under my user name). Which I still find odd, in that my user is the owner (with rwx), and the user:group info is: user:user. But I'm quite new to Linux.
File permissions, again: With the above, commands like drush status worked, but running (as the user) drush cc (or cr) gave an error that pointed to another file permissions issue. (Sudo could run those commands OK, but it would be weird to use sudo for some drush commands and not for others -- and who could remember.) Which traced to: in the /home/user folder, there is a hidden .drush folder [with a factory subfolder containing a bunch of php command files]. The install process had set ownership of that to root:root. There is more than one way to handle this, but for now I changed ownership (chown) to user:user, and that at least allows drush cr to work.