Which almost certainly has different pixel-clock and timing limits. Most 9800s don't even have an HDMI port.

So, you're using a utility for writing mode entries to the registry on Window Vista... to generate modelines for X11. And you're actually wondering why that doesn't work? The mind boggles.

Because it's a hack. The HDMI 1.3 spec does not define the modes you are trying to use, so the GPU firmware and drivers do not define them or support the clocks needed for them either.
The open-source radeon driver aims to reproduce the functionality of the OEM AMD driver, not an unofficial third-party "patcher". ATI/AMD put those limits there on purpose, honouring them isn't a bug.

GLX has nothing to do with pixel clocks or mode timings.

It seems that if you want to apply a similar hack to the radeon driver, it's open-source and you're free to do so. Not implementing hacks to support things the hardware was never designed to do is not a bug.
By all means report it, but don't expect anyone to get real excited about "fixing" it with any kind of urgency.

Probably by specifying modelines that aren't trash. Get rid of those and use xcvt (e.g. cvt -r 1920 1080 120) or a decent online calculator.
Are you copy-pasting random forum threads from 2012 or what?

Even with suitable modelines, a Radeon HD5770 has HDMI 1.3 and displayport 1.1. It won't have enough bandwidth to do 1080p at more than 75Hz over HDMI, and it probably won't over DP either unless you disable audio and screw around with module parameters.
Your monitor might be able to do 144Hz FHD, but it wasn't a thing when that GPU was made.
'read-edid' is almost as ancient, and it won't work as intended with a modern monitor either.

Aside, ahem:

...

That is not the free driver, it's an ancient (~2015) proprietary installer from outside the repositories (just like Don'tBreakDebian cautions you about), and I'm fairly sure it doesn't even support the HD5770 or load on a modern kernel. How and why is it involved?

That's dbus activation failing to start whatever is providing UPower.PowerProfiles (likely because the shipped definitions expect systemd and the "Exec" entry is /bin/false, see /usr/share/dbus-1/system-services/org.freedesktop.UPower.PowerProfiles.service), which implies that it isn't already running, or if it is, it didn't register on the system bus.

Note sysvinit has no service supervision, so it'll say tlp-pd is "started" even if it later exited or crashed. Check that the process is actually alive.
The manual suggests tlp-pd takes a '--debug' flag, that's probably worth a look too.

It appears Devuan does not ship a sysvinit script with tlp-pd (as usual, it's just the Debian package and no attempt was made to ensure it works properly without systemd), so somebody will need to write one.
I don't have any Devuan installs on laptops or any interest in tlp, so that someone isn't me. It should be trivial though, find an init script template and have it start /usr/sbin/tlp-pd after dbus and tlp.
...or just ask your artificial-stupid of choice to convert /usr/lib/systemd/system/tlp-pd.service, this is a pretty good example of something they should be able to do without screwing up.

Ed. Upstream just added an init script.
Grab https://github.com/linrunner/TLP/blob/main/tlp-pd.init, stick it in /etc/init.d as tlp-pd, make it executable, and enable it with update-rc.d.
Then either reboot or start the service manually then logout/login to kde.

Should work, YMMV, etc. Again, I have no desktop Devuan installs. vOv.

That's not even remotely how any of this works.
Init, whatever it may be, is a userspace program and interacts with kernel facilities the same way any other userspace program does (i.e. mostly via libc, or using public kernel ABIs).
No init links directly against the kernel or "locks" anything, and the claim that systemd somehow prevents the kernel "communicating" with "various tools" is completely ridiculous.

Can we really not discuss init systems in here without resorting to irrelevant, misinformed systemd FUD? Systemd wasn't even mentioned in the OP, the question is why we aren't exploring a switch to one of the other options.

LightDM is not a bootloader, it's a Display Manager.

To eliminate GPU drivers and X11, I'd suggest testing boot to a TTY (e.g. "recovery mode" or whatever it's called, or specifying a non-graphical runlevel on the kernel command line), and/or disabling KMS by passing 'nomodeset' on the command line.

Once you have a working TTY login, you have an environment to capture logs and troubleshoot any issues with the GUI.

If my computer says *anything* to me, or tries in any way to be "helpful", "conversational", or otherwise waste my time unless explicitly asked to do so, I'll rip out its operating system on the spot.

*Click*
*BANG*

On OP's other similar suggestions... The moment an "installer" starts to "probe the user" (noisily or otherwise, but especially if it's noisily) is the moment I throw that disk in the trash.
A computer is a tool, it should do exactly what the user tells it to do and nothing more. No "volunteering", no "helpful" interjections with unsolicited advice, suggestions, or options.

What is proposed here is essentially Clippy, but infinitely more annoying and integrated into the whole system. Just. No.

amd64 is for any x86_64, Intel or AMD. The port is named that because AMD invented 64-bit x86 while intel was still floundering about with Itanic.

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