Is literally retrocomputing at this point (for the love of doG, at least put a C2Q in it), and you'd be better off dual-booting a stripped-down Windows XP. With those specs, WINE is "bloat".

Nothing of the sort, simply saying it the way it is. If your graphics drivers advertise that they can do vulkan (which mesa can, on the CPU), then things will naturally try to use it.
None of this is steam at fault, it's simply a consequence of trying to run modern software on ancient hardware. Crying "bloat" any time you run into hardware limitations doesn't change reality.

Steam uses wine to run windows games. The differences between "vanilla" wine and steam's "proton" fork are minimal, and usually confined to the latter being optimised and/or patched for gaming as opposed to general application compatibility.

This has nothing whatsoever to do with steam. Proton (and most other "gaming" focused wine builds and frontends for that matter) defaults to enabling DXVK (and VKD3D for DX12) , because that is by far the best performing DirectX API translation layer available.
DXVK will use whatever vulkan renderer the host graphics drivers advertise, and on antique GPUs that could well be the lavapipe CPU implementation... Provided by mesa.

If your GPU doesn't support vulkan, you'd be better served by reading the documentation and setting the appropriate environment variables, rather than wasting perfectly good oxygen bitching about steam and "bloat".

Betcha a cookie this is yet another case of the conspicuously still not backported to stable network-manager packaging SNAFU.

The only systemd-related artifact here is x-systemd.automount, and while it obviously won't work, it won't hurt anything either as none of the scripts involved look at it.
Maybe try actually addressing the problem, rather than just looking for excuses to bitch about systemd?

How is your networking configured? if you're using networkmanager, see this thread.
If you're using ifupdown, we'll need /var/log/boot (or wherever you have your init logs going to), and you should probably have a look for anything related in /var/log/syslog (or /var/log/messages, or wherever you have general daemon logging going) and the kernel ring-buffer (i.e. dmesg).

Also, repeating for more visibility because your fstab listing is almost unreadable:
use code tags

Removing the launcher for that module was an especially asinine move, in a growing list of asinine moves from KDE of late. The justification apparently being to "get people to report bugs instead of working around them, we'll tell them how to find it if they need it"...
I recommend making a .desktop file / application menu entry for it for the future.
Other "hidden" kde things that may be of interest:
kdebugsettings
kcmshell6 kcm_qtquicksettings
kcmshell6 --list in general
qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole (kwin debug console)

Do you actually have a (session) dbus instance running? How was it started?
The trick is that you want one session bus, and everything in your session to be using the same bus address.
So "DBUS_SESSION_BUS_ADDRESS,unix:path=/run/user/1000/bus" or whatever you are setting the session bus address to needs to be the same as what you passed to dbus-daemon when you started it.

I use OpenRC user services to start (and supervise) dbus-daemon explicitly, so I know that it was launched with '--address ${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus'. This may not be the case in your setup, which is why I said "Something along the lines of" rather than "copy-paste this".
If you're using dbus-launch, you can a: Manually ensure DBUS_SESSION_BUS_ADDRESS is already set in the environment dbus-launch runs with (and set the same for anything that needs to connect to it) b: Make sure everything that needs to connect to the session bus inherits dbus-launch's environment (since it will set DBUS_SESSION_BUS_ADDRESS itself if it is empty) or c: Use dbus-update-activation-environment as EDX-0 described above.

When you launch applications with dbus-launch or dbus-run-session, you often end up creating a new dbus session just for that application - (so it will start, but it won't be able to do IPC with anything else), or in the case of something like hyprland, starting a session but not propagating the bus address to applications started later (usually because something, like a greeter or launcher, is stripping environment). Launching subsequent applications with dbus-run-session risks starting another isolated dbus session, and you end up  back in scenario 1.

Sounds good on paper, until you realise "ncurses like" means "doesn't actually use ncurses, instead reinvents it in zig". It's not packaged in Debian, and while there are ebuilds for Gentoo, that just makes needing to install the whole zig toolchain for a text box slightly less annoying.

I was getting dangerously close to doing that myself, but between gathering patches from not-dead forks and a couple of my own, I think I might have got tuigreet into a mostly usable state. It's still rust and it's still part of the "1200 crates" ecosystem, which is irritating, but at least that's a toolchain I already have installed for firefox & co.

Honestly, this is all in service of my biennial "can wayland completely replace X yet / can you comfortably run a desktop system without an xserver installed" investigation.
The answer is still "not really" (unless it's GNOME, maybe).

So, uhh, export the correct bus address? There are about 50 ways to set an environment variable system(or session)-wide.
Something along the lines of:

$ cat /etc/profile.d/zz-env-hacks.sh 

#!/bin/sh
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus"
fi

if [ -z "$XDG_RUNTIME_DIR" ]; then
    export XDG_RUNTIME_DIR="/run/user/$(id -u)"
    if [ ! -d "$XDG_RUNTIME_DIR" ]; then
        mkdir -p "$XDG_RUNTIME_DIR"
        chmod 700 "$XDG_RUNTIME_DIR"
    fi
fi

(or the relevant part thereof) will probably do it, though I don't have a Debian/Devuan install with a GUI to confirm.
Something similar could also go in your users shell profile or some other script that is sourced during hyperland (which I also don't use) startup of course.

The list of packages this byzantine "installer" looks for (and tries to install, including tampering with sources.list to add unstable on some distros *barf*) can be found in installer/distros.dat after unpacking the .run file.
However, since it has no explicit entries for any version of "devuan" and the OP didn't bother to tell us which options were passed to the internal install script or provide the output in --debug mode (which likely would have told them exactly what it failed to find and why), I suppose we'll all have to guess.

So much for, and I reiterate with more emphasis:

@deepforest If you're going to install software from outside the repos, on a distro that upstream doesn't even claim to support (note Debian being "present in supported distros" does not mean it will detect Devuan successfully), you get to keep all the pieces. Even if you get this to install, it will louse up your system with untracked files in unusual locations, just as the wiki warns.

We might be inclined to help, but if you want to do unsupported, not-recommended, oft-warned-against things to your system, you need to put in more effort than "Why do not want to install" - starting with at least a cursory investigation of how the installer works and gathering useful debug output.
This is not Windows, we do not run executable installers from manufacturer websites. Installing software from the stable repositories is "easy mode", running (or porting from) unstable, building from source, or using third-party scripts is "expert mode" and comes with the expectation that you are able and willing to put energy into solving your own problems.

Riiight, so, people not wanting to do your homework for you or run unknown install scripts for software they don't need is "lazy"... Guess I'll be "lazy" too then, good luck.

foo-devel is a RedHat thing, the script knows nothing about Devuan and it's a near-certainty that it's just misdetecting the distro... Which, again, had deepforest provided the output of hplip-install --debug we would know rather than have to take educated guesses at.

I mean, it took me all of about a minute to extract the install script and see it had a debug flag, surely Mr. "runs unstable and installs things from SourceForge" could have done that too

*Aside, if anyone is wondering why I'm not spoon-feeding the answer (besides just generally being a bastard OFC), it's right here in the attitude:

Why would anyone here know (or care) about some random executable "installer"? As already stated (more than once) the packages in the repos work fine, and that's what people who don't want a broken system use.
If you really want to know, ask whoever provided that .run file - or extract it and look at whatever pre-install checks it's doing yourself, since it's probably just a bunch of shell concatenated with a compressed archive. My bet is that it's looking for Ubuntu package names or specific versions, but that's for you to determine if you insist on installing "fresh" software in weird formats.

cdemu works fine without systemd, it's only needed for dbus activation of the daemon - which you can do any way you would usually start a user daemon.
If the debian package (wherever you got it, since it's not in the stable repos AFAIK) has a depend on systemd, remove it and rebuild the package... Or just install cdemu from source to begin with.

And? You're running unstable with a bleeding-edge kernel and ancient out-of tree proprietary drivers. Did you expect that not to break?

Either patch the nvidia nonsense yourself or wait for Debian to do so. Nvidia probably never will, they're regularly behind on kernel kernel changes with their current driver, let alone one released over six years ago.