No. I don't reuse passwords, the probability of somebody running a MITM attack on my login to a random forum is miniscule, and even if they did and managed to impersonate me here, who the hell would care?

It is. If you do somehow get redirected to the login form over HTTP (which I haven't seen myself), that's easy to prevent on the browser end with the likes of the HTTPS-everywhere extension.

This ubiquitous bleating about HTTPS with complete disregard for attack surface, user responsibility and basic password hygiene, or even relevance is quite tiring.
Security is a process, not "if [[ ${URL bar} =~ "padlock icon"  ]]; then sleep; else panic; fi".

That script is a simplified version of what Gentoo and Slackware (and likely other non-systemd distros) are using to start pipewire.

PW doesn't daemonise properly, exit with the user's session, or manage it's own instances and ordering, instead relying on systemd user units for all that.
The 1 second sleep is required for reliability, and killing pipewire processes avoids not having sound after a logout -> login (unless you have elogind and KillUserProcesses=yes, which kills everything).

Personally I got rid of all that hacky mess, and am using daemon to manage pipewire (and cdemu, which has the same problems). Binding to the user session requires [e]logind and backporting daemon from unstable, but also neatly solves the "pipewire doesn't exit with session" problem.

TBH the first thing I'd do is see if the system will boot to single user mode (pass "single" or "1" on the kernel command line)... But again, boot issues are difficult to diagnose remotely, so more options more better.
I mention sysrq because when getting a working shell to see what's going on or fix something is the goal, sometimes a large hammer (e.g. "Kernel, kindly kill with fire everything except init") is the most effective tool.

Magic sysrq is a kernel facility, docs here.
SAK (ctrl-alt-sysrq-k) is Secure Attention (or Access) Key and kills everything on the current tty except login.
Unraw (ctrl-alt-sysrq-r) switches the keyboard to xlate mode, which can be useful to wrest keyboard control from a misbehaving or crashed X process.
The term and kill commands might also be useful, in the case some init script or daemon has gone rampant

You might try the usual tricks, like issuing a sysrq unraw or sak at an unresponsive login prompt, booting into runlevel 1 or S from the kernel command line, or at a pinch just passing sulogin (or even just sh) as init to boot direct to a shell and bypass normal startup altogether.

The "recovery shell" you mention is probably either runlevel 1 (or the synonymous "single") as above, or an initrd shell you'll be dropped into if the root fs is unavailable. Pretty sure Devuan has those and always has.

The apparmor stuff is probably harmless, for some unfathomable reason it keeps getting pulled in unless you pin it, then complains because it's not configured properly. In all it's kind of difficult to diagnose something like this from here without seeing the boot process.

Personally I think Devuan should move to openrc as default, and pool init documentation (and service scripts) with Gentoo, Artix, Alpine and Nitrux (and maybe even GhostBSD, which is pretty cool as far as BSD desktops go ).
But that's just me. While it does still do what it should, I have no particular love of sysv, insserv or LSB.

Browsers aside, I prefer "If you not having problems with discourse, then you need to worry.", or simply "If you're using discourse, you have a problem."
That thing is the most obnoxious "forum" software I have ever had the misfortune to encounter.

Of course, and the link I dropped points to the Devuan package index.

$ apt show dma
Package: dma
Version: 0.13-1+b1
Priority: optional
Section: mail
Source: dma (0.13-1)
Maintainer: Arno Töll <arno@debian.org>
Installed-Size: 165 kB
Provides: mail-transport-agent
Depends: ucf (>= 0.28), debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.33), libssl3 (>= 3.0.0)
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
Homepage: https://github.com/corecode/dma
Tag: implemented-in::c, interface::daemon, mail::smtp, mail::transport-agent,
 protocol::smtp, protocol::ssl, role::program, works-with::mail
Download-Size: 52.1 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.devuan.org/merged daedalus/main amd64 Packages
Description: lightweight mail transport agent

Sure:

deb http://deb.devuan.org/merged daedalus main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-security main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-updates main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-backports main contrib non-free non-free-firmware

The real elephant in this room is, is anyone in the know actually going to answer the OP's question:

Additionally:
[When] do users of Devuan stable need to convert? How will this be handled?

This:

Clearly doesn't apply to Devuan, and there is nothing in the Daedalus release notes. Do we actually have a plan yet, or are we still at the "futile arguments" stage?

Don't get me started on this idiotic HiDPI and "fractional scaling" nonsense everyone is so keen on these days (not least because it's the wayland "way").

We have DPI, a real physical property of the display device to base font scaling on, which would work just swimmingly if X didn't lie and always return 96DPI (which is a bug/regression) and GUI toolkits didn't ignore server DPI because of it.

But instead of patching the bug and fixing the mess of toolkits assuming buggy behaviour and doing their own thing, now we're hardcoding 96DPI all over the place (I'm looking at you, wayland and GTK) and adding expensive (and often blurry or unreliable) global scaling in the compositor...
So instead of selecting a preferred font size and automatically getting correct rendering for the connected display, the user gets fonts sized for an "average" display of 15 years ago and has to poke a "make it bigger" slider like a caveman until it doesn't look too horrible.
This, apparently, is progress.

Indeed, and that's my main problem with wayland (and systemd, and almost everything else Redhat-IBM is doing ATM).
It's not that the software is bad, it's the way it's being agressively pushed on users and downstream distributions regardless of whether it or they are ready, by creating dependencies and intentionally breaking compatibility in ways that effectively force the use of the entire RH software stack.

Sentiment to the effect of "this is you wakeup call" "drive adoption" "force users to..." "time is up" "get with the program" etc. are not difficult to find amongst the developers involved, and this further speaks to the idea that Redhat-IBM believes they control enough of GNU/Linux development to dictate terms to other projects, end-users, and the rest of the community.
This is obnoxious, it smacks of corporate interests, and flies in the face of the "bazaar" development model that gave us so much freedom of choice to begin with.

The console bell is something I find incredibly irritating, so while do I know how to kill it with fire I'm probably of rather less use when it comes to the opposite.

That said, (assuming we're talking about a real hardware pc-speaker here, not pc-speaker emulation) I'd probably start with going through the configuration items (inputrc / xset etc.) and potential permissions issues listed in the usual places. Most of it is biased towards eradicating the bell, but such advice should also work in reverse.

That the 'beep' command works suggests to me that your problem is likely either terminal configuration related, or something (e.g alsa or pulseaudio) is trying to redirect bell output to your sound card.
In the alsa case, IIRC that's controlled by e.g. SND_HDA_INPUT_BEEP and SND_HDA_INPUT_BEEP_MODE in the kernel config. As for pulse... Don't use, don't know, sorry.

Ed. Out of interest, does this beep?

#!/usr/bin/env python
"""Beep PC Speaker using Linux evdev API.

To make /dev/input/by-path/platform-pcspkr-event-spkr device available, run:

    root# modprobe pcspkr
"""
import ctypes
import math
import os
import time

EV_SND = 0x12  # linux/input-event-codes.h
SND_TONE = 0x2  # ditto
time_t = suseconds_t = ctypes.c_long

class Timeval(ctypes.Structure):
    _fields_ = [('tv_sec', time_t),       # seconds
                ('tv_usec', suseconds_t)] # microseconds

class InputEvent(ctypes.Structure):
    _fields_ = [('time', Timeval),
                ('type', ctypes.c_uint16),
                ('code', ctypes.c_uint16),
                ('value', ctypes.c_int32)]

frequency = 440  # Hz, A440 in ISO 16
device = "/dev/input/by-path/platform-pcspkr-event-spkr"
pcspkr_fd = os.open(device, os.O_WRONLY)  # root! + modprobe pcspkr
fsec, sec = math.modf(time.time())  # current time
ev = InputEvent(time=Timeval(tv_sec=int(sec), tv_usec=int(fsec * 1000000)),
                type=EV_SND,
                code=SND_TONE,
                value=frequency)
os.write(pcspkr_fd, ev)  # start beep
try:
    time.sleep(0.2)  # 200 milliseconds
finally:
    ev.value = 0  # stop
    os.write(pcspkr_fd, ev)