„Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t?”

A Drush, ezzel a paranccsal: $ drush site:install. Használhatod a parancs --help kapcsolóját a leírásának elolvasásához vagy online itt találod. (Ezen az oldalon ne felejtsd el kiválasztani a Drush-od verzióját, előfordulhatnak eltérések a verziói között.)

„[…] mikor lehet megadni az adatbázis infókat, mert ugye anélkül nem fut le a telepítés”

Vagy még futtatás előtt beleírod a settings(.local).php fájlodba (ekkor keress rá a $databases változóra, hogy megtaláld a leírást benne, hogyan lehet), vagy pedig magának a Drush-parancsnak adod át őket bemenetként (erről pedig az előbbi --help kapcsolóval olvashatsz).

„[…] de nincs egy összefoglaló kép az egészről.”

Ezt nem értem pontosan, mire gondolhatsz, de a Composer alfája és omegája a két fájlja a projekted gyökerében: a composer.json és a composer.lock. Ezek (szinte) minden információt tartalmaznak, amiből képet kaphatunk a projektünk összetételéről.

„És akkor ott van az, hogy globálisan, vagy lokálisan települt-e?”

Feltételezem, itt a Composer-re gondolhatsz. A projekted gyökerében állva egy $ whereis composer paranccsal kilistázhatod az ilyen nevű futtatható binárisokat, amik fellelhetőek az oprendszered (Linux vagy macOS – Windowst nem tudom) $PATH változójában felsorolt könyvtárak valamelyikében. Nekem például egy ilyen eredményt ad:
composer: /usr/local/bin/composer /var/www/html/vendor/bin/composer

Nálam ebből az első a globális, a második a projekt függőségeinek könyvtárába (vendor/ mappa) telepített, tehát a lokális. Ezeknek eltérő lehet a verziója és a beállításaik, ezért sokan ha tutira akarnak menni, szeretik fixen kiírni a projekt saját Composer-példányának az útvonalát, nehogy azon haljon el a szkript, hogy tévedésből a globális példányt keresi, ami viszont ritkán szokott telepítve lenni a szervereken.

„tehát az "install" szót használja, ami telepítést szokott jelenteni”

A drupal/core-recommended projektsablon többek között igényel egy drupal/core-project-message nevű Composer-bővítményt is. Ez a kis kiegészítő annyit csinál, hogy kiolvassa a „szülő” projektsablon composer.json fájljából az ott megadott üzenetet és megformázva visszaszajkózza a telepítési folyamat egy bizonyos pontján a parancssorba. A hátteréről ebben a 2019-es ticketben olvashatsz, ez a kettő pedig még nyitott, de szintén ehhez kapcsolódik. Ha gondolod, az utóbbi alá odakommentelheted az észrevételed az „install” szó helytelen használatáról. Ha szeretnéd, szívesen segítek megfogalmazni.

„[…] mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket”

Így van, ahogy írod, annyi pontosítással, hogy itt nem a Drush-ról van szó, hanem a Composer-ről, hiszen a nyilvántartást a telepített komponensekről és azok verzióiról (és még sok másról) a Composer vezet, nem a Drush.

„le lehet valahogy tiltani a grafikus felületről indítható frissítéseket?”

A kódbázis grafikus felületen keresztül való piszkálását szándékosan szorítjuk már háttérbe, már a 10.4-es alaprendszerből kikerült ez a régi örökség, a mögöttes érvekről is ugyanitt lehet olvasni. A letiltás ötlete jogos, ám életszerűtlen, hiszen általában 1–2 adminisztrátor végzi a webhely frissítését, ők pedig azért csak meg tudnak állapodni maguk között a mikéntjéről.