Thanks so much! 
I’ll try and test properly during the weekend and let you know.
In the meantime: yes, unplugging the one single external USB 3.0 hub and/or disabling the wireless mouse receiver seemingly allows me to put the PC in suspend… but then it will not wake up properly, leaving the screen black and inert. 
Even though that change doesn’t really help that much, at least that’s a little bit progress. Try to post more logs after removing those devices from your system. Perhaps there will be different errors in the logs that may help identify what remaining issues are still causing problems.
Exactly which methods did you test to wake from sleep? Did you try using the power button and the terminal. What type of keyboard are you using? If you are using a wireless keyboard try replacing it with a wired model.
Here’s new logs after unplugging the Logitech wireless receiver and using a regular usb mouse (sorry, I don’t have a PS/2 mouse anymore):
https://termbin.com/1wg0
https://termbin.com/6ick
To try and wake up the PC I used a keypress on my usb keyboard.
When I tried and use the power button I failed: it seemed to simply do nothing or turn off the PC directly.
EDIT: When, after disabling all usb devices from powerop, I managed to put the system in suspend and tried waking it up with power button… it just had the same result, fans spinning and keyboard lights lighting up but black screen and monitor apparently still in standby. 
I’ve never been able to use the on/off (power) button to do anything other than its intended use. Move my mouse, hit the space bar or any key, works just fine in Garuda, Arch, or Windows. But not the power button. Not on any laptop or desktop computer I’ve own or used going back to the 1980s.
Now, this is really strange.
After all the rest failed I just tested my Garuda USB stick again: booting from the USB live the system sleeps and wakes up without a problem.
With the same USB peripherals that apparently block the system from sleeping/suspending/waking up when booting from my bare metal installation.
What gives? What big change has intercurred since the live USB version and the actual updated installed one that broke this on my system?
i’m no software expert but this smells like a local .config issue.
If it is, I really need some help because I don’t have a clue about it… 
I forgot to report on this: tried it and it did not make a difference, unfortunately. 
I suspect the key to comprehend this is in the fact that on live usb it sleeps/wakes regularly, while on the constantly-updated-bare-metal-installed version it does not. 
Unfortunately I do not have the skills to debug and correct this, and not having a working suspend/sleep state is kind of a no-go for me. But I’m really liking Garuda approach, so I keep trying to solve this issue and not change distro alltogether. 
In theory this could be the result of an update to any installed package on your system. The most likely suspect for creating a suspend issue IMO is usually a kernel update (if suspend works properly on a live disk). I would continue testing alternate kernels in the hope that one may improve your situation.
The other thing that often impacts suspend is your firmware version in use. I would search your working live disk to find out which versions were in use for linux-firmware or any other firmware packages installed on the live system.
Record the versions of the firmware in use on the live system and then downgrade the equivelent firmware packages on your system installed to metal.
See the Arch Wiki for details on downgrading:
Thanks a lot, I’ll try ASAP. 
Forgive the very basic question but: how can I check the linux-firmware version on the live (or metal) system? Via octopi?
Yes, search the installed firmware with octopi.
We also have an AUR utility downgrade preinstalled for downgrading packages in garuda. It makes the process a lot easier.
man downgrade
Should tell you pretty much how to use it.
I do know that I had to downgrade powerdevil and ddcutil in Arch + KDE just a few days ago–regressions–and that may have some bearing, or not.
…but Octopi in live usb said at startup that “Pacman Database is missing” and do not show anything. 
Tried to check updates and this showed up:
I downgraded both linux-firmware, linux-Firmware-whence, linux-kernel and linux-kernel-headers via the command “downgrade”:
EDIT: in the meantime I managed to reboot using the LTS kernel that I installed for a previous try (and luckily never uninstalled ^^)
Why did you downgrade the kernel tbg advice only asked firmware? should have just tried the LTS kernel instead. The path you went needed to both regenerate initramfs, and re-run the dkms hooks for each and every module you have manually.
Here is what you needed to do if you went that path,
first, remove the existing modules for the kernel you downgraded,
module names can be found in /var/lib/dkms and their current version with pacman
sudo dkms remove <module-name>/<module-version> -k <kernel-version>
then install the module for the downgraded module
sudo dkms install --force <module-name>/<module-version> -k <kernel-version>
eg,
sudo dkms install --force nvidia/545.29.02 -k 6.5.9-zen2-1-zen
then rebuilt initramfs,
sudo dracut-rebuild
following a grub update
sudo update-grub
Here is what you need to do in order to recover,
Either,
sudo pacman -S linux-zen linux-zen-headers
This will rerun all the hooks again and simultaneously update the linux-zen kernel again.
Or,
linux-firmware one at a time to test and not the kernel.Next, to test with older kernel version,
Install the LTS kernel,
sudo pacman -S linux-lts linux-lts-headers
Then while booting from grub → advanced menu select linux-lts. You can set this as your default kernel to boot with using garuda boot options (You can do this once you have successfully restored your system).
Yeah, I knew I screwed up already when I was doing it… sorry. It seemed too easy to be true. 
Ok, I managed to restore a previous snapshot (snapshots and btrfs assistant are a WONDERFUL feature, btw) and now the system boots again.
I’ll do some more testing downgrading the firmwares: should I search and downgrade all the package with the word “firmware” in the name or just linux-firmware?
I’m asking because previously, when I rebooted using the LTS kernel, linux-firmware was still downgraded and suspend/sleep was not working, nothing seemed to have changed.
Thanks again for all the effort all of you are putting in trying to help me, I really appreciate it. 
EDIT: small update, after restoring linux-zen I tried and downgrade only linux-firmware and suspend seemed to work! … but only to again failing to wake up, with black screen etc 
I believe we both have same firmware packages,
pacman -Qs firmware
local/alsa-firmware 1.2.4-3
Firmware binaries for loader programs in alsa-tools and hotplug firmware
loader
local/b43-fwcutter 019-4
firmware extractor for the b43 kernel module
local/fwupd 1.9.7-1
Simple daemon to allow session software to update firmware
local/gnome-firmware 45.0-1
Manage firmware on devices supported by fwupd
local/linux-firmware 20231030.2b304bfe-1
Firmware files for Linux
local/linux-firmware-whence 20231030.2b304bfe-1
Firmware files for Linux - contains the WHENCE license file which
documents the vendor license details
local/sof-firmware 2023.09.1-1
Sound Open Firmware
If not doing the pacman -Qs firmware command should display all packages with firmware in it. As you can see all but linux-firmware seems relevant to downgrade.
In the future I think you should stay away from downgrading the kernel unless you are experienced and intend to bisect the kernel.
There could be a ton of packages that could possibly be responsible for causing this problem. After you have downgraded your firmware, then the next most likely candidates are any power management utilities (such as powerdevil, powertop, upower, etc). Perform a search for any package you have installed that contains the word “power”. Then downgrade any power management utilities that you have installed to the original version in use on the live boot disk.
Unfortunately, as you are now discovering it can be a very time consuming process to investigate which package is causing a problem when you have performed a large system update. That is why it is best to update very regularly, because it reduces the amount of packages you potentially have to downgrade to discover where the problem originated from.
I would advise you to downgrade only one package at a time, and reboot between downgrade operations.
Good luck on your investigations.