I use devuan (mainly chimaera) on a few servers, and never noticed this bug.  If it had affected me, I hope that I would have noticed pretty quickly... My completely uninformed guess is that not many people use backports of rsyslog, as it seems none of the other versions were affected.  What does the backports version of rsyslog do that I'm missing?

I'm still not understanding something here.
Do you have two NICs (eth0 and eth1)?
If eth1 = LAN as posted earlier, then set up a static IPv6 network there.  https://en.wikipedia.org/wiki/Reserved_IP_addresses use one of the "Private internets" ranges (64:ff9b:1::/48 for example).  eth0 will receive whatever address is assigned when connecting to ISP.  In your postfix conf, use the static address that you've chosen for eth1.
(Note, I don't actually use IPv6, maybe someone with experience with this can chime in.)

You can do the same thing even if you only have one physical device, with a virtual interface (for example, ifconfig eth0:1 64:ff9b:1::1).  I do this with IPv4 addresses and postfix.

AFAIK, there's currently no other way to configure postfix for dynamic IP addresses, except for inet_interfaces = all.  I could be wrong there, but from skimming through http://www.postfix.org/postconf.5.html I'm not seeing it.

This is set by your domain registrar.  Log into the site that you registered the domain name, and add a CAA record using the issuer of your certificate.  https://letsencrypt.org/docs/caa/ may have more information.  One of my CAA records looks like this:
example.com 1799 IN CAA 0 issue "letsencrypt.org"

Unfortunately, I don't know what to make of those handshake failures.  That seems unrelated to caa.

OK, here's where I'm at now.

First, I edited /boot/config.txt and attempted to change the kernel line to the version that I had installed via apt as follows: kernel=vmlinuz-5.10.0-19-arm64
The "file" command reported both files (the previous kernel8.img and the vmlinuz-5.10.0-19-arm64) as "Linux kernel ARM64 boot executable Image, little-endian, 4K pages" -- so I thought it just might work.
When I rebooted, the system was stuck at the initial color "rainbow" screen.

I resized my boot partition (it was 128MB on the ascii image, but 256MB on the chimaera image).  I downloaded the file rpi-3-devuan-chimaera-5.10.110-arm64-ext4-2022-11-25.zip from the page https://arm-files.devuan.org/RaspberryPi%20Latest%20Builds/  ... then using dd I overwrote my boot partition with the one from that image.  At first it would not complete the boot due to missing partition (I forgot to edit cmdline.txt).  After I got that straightened out, it did boot into Linux devuan 5.10.110 #1 SMP PREEMPT Fri Nov 25 00:43:14 CET 2022 aarch64 GNU/Linux

So I guess that part is solved, sort of.  I was hoping there would be a simpler way to just upgrade the kernel (like it works in amd64).

Also, upgrading the kernel didn't even fix the iptables problem.

# iptables -A INPUT -s 1.2.3.4 -j DROP
iptables/1.8.7 Failed to initialize nft: Protocol not supported
# iptables -V
iptables/1.8.7 Failed to initialize nft: Protocol not supported

I think I've got the solution for this, though.
I found on https://superuser.com/questions/1480986/iptables-1-8-2-failed-to-initialize-nft-protocol-not-supported:

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

I had to copy the /lib/modules/5.10.110 from the latest image file to my live system, too (which of course I forgot to do previously).

Now, iptables seems to be functioning correctly.

The only question remaining is, whether or not there's a simpler kernel upgrade process.  At least things are working again, and it is possible to upgrade kernel, just a bit more time-consuming than I'm used to :-)

FYI, after adding repository, apt install loksh says...

Preparing to unpack .../archives/loksh_7.1-1_amd64.deb ...
Unpacking loksh (7.1-1) ...
Setting up loksh (7.1-1) ...
update-alternatives: error: alternative path /bin/loksh doesn't exist
dpkg: error processing package loksh (--configure):
 installed loksh package post-installation script subprocess returned error exit status 2

loksh is located in /usr/bin, not in /bin
This occurred in devuan chimaera

Phooey.  I was hoping another process (the old pihole?) was holding on to that port.  You can't connect, because the service is not running.  The service won't start (or rather, won't stay running) because of... something yet unknown.
Earlier you had posted this from your log:

[2022-08-19 18:05:28.696 1140M] Error opening IPv6 telnet socket: Address family not supported by protocol (97)

Would you mind trying this, add this line into the file /etc/pihole/setupVars.conf

IPV6_ADDRESS=

Then run

# service pihole-FTL start

If it doesn't start properly, check /var/log/pihole/FTL.log for other clues.

Also, in the web interface, there is a section "Pi-hole diagnosis" under the "Tools" menu.  I'm not sure whether or not that is useful.

If all else fails, nuke it (including configs) and re-install.  Sometimes that is quicker (but less satisfying) than finding the actual problem.

What is the output of:

service lighttpd status

FYI, my (very-old) FTL.php contains this:

function connectFTL($address, $port=4711)
{
	if($address == "127.0.0.1")
	{
		// Read port
		$portfile = file_get_contents("/var/run/pihole-FTL.port");
		if(is_numeric($portfile))
			$port = intval($portfile);
	}

	// Open Internet socket connection
	$socket = @fsockopen($address, $port, $errno, $errstr, 1.0);

	return $socket;
}

The next place to look would be /etc/pihole/setupVars.conf... check if anything looks off in there.

Oh, and don't forget the log files: /var/log/pihole/FTL.log and /var/log/pihole/pihole.log

This is strange:

$ aptitude versions firefox-esr
Package firefox-esr:                              
p   78.14.0esr-1~deb10u1             oldstable     500 
i   91.12.0esr-1~deb10u1             oldstable-sec 500 

Package firefox-esr:i386:
p   78.14.0esr-1~deb10u1             oldstable     500 
p   78.15.0esr-1~deb10u1             oldstable-sec 500 

It appears firefox-esr:i386 is indeed at 78.15.0 with beowulf (above).  However, using ascii sources gives this:

$ aptitude versions firefox-esr
Package firefox-esr:                              
p   68.10.0esr-1~deb9u1              oldoldstable  500 
p   91.11.0esr-1~deb9u1              oldoldstable- 500 
i   91.12.0esr-1~deb10u1                           100 

Package firefox-esr:i386:
p   68.10.0esr-1~deb9u1              oldoldstable  500 
p   91.11.0esr-1~deb9u1              oldoldstable- 500 

I suppose you could (temporarily) change sources to ascii, apt-update, install firefox-esr (91.11.0), then restore sources to beowulf ...

Apologies for the late response.  It was, apparently, a hardware problem after all, although I'm not sure exactly what.  Something with the CPU or motherboard (I didn't have a spare of either that I could interchange and narrow down the problem).

It actually *did* boot the amd64 live desktop dvd.  :-)   Installation went pretty smoothly from there.

This machine doesn't look like the one pictured on your link, snork.  The EFI situation could be similar though, I don't really know.  It does seem to be from the same era, though.  This is an all-in-one thing (basically the hardware is all mounted behind/under the screen.  no tower, more difficult to replace individual parts).

inxi reports this as:

System:    Host: imac Kernel: 4.19.0-14-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.12.4 tk: Gtk 2.24.32 
           info: xfce4-panel wm: xfwm4 dm: SLiM 1.3.6 Distro: Devuan GNU/Linux 3 (beowulf)
Machine:   Type: Desktop System: Apple product: iMac6,1 v: 1.0 serial: <> Chassis: type: 13 v: Mac-F4218FC8 
           serial: <> 
           Mobo: Apple model: Mac-F4218FC8 v: DVT serial: <> UEFI: Apple v: IM61.88Z.0093.B07.0706281250 
           date: 06/28/07 
CPU:       Topology: Dual Core model: Intel Core2 T7400 bits: 64 type: MCP arch: Core Merom rev: 6 L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 8645 
           Speed: 1589 MHz min/max: 1000/2167 MHz Core speeds (MHz): 1: 1101 2: 1049