Two of your results narrow this down a lot.
First: while nothing is listening on 3389, every Remmina setting is irrelevant - security negotiation can only matter once a server socket exists. The client side is not part of the problem at the moment.
Second: the bare krdpserver -u user -p pass hanging as well means systemd is not involved either. The block is inside the binary’s own startup, before it ever binds the port. And since even this morning’s manual start never opened the port, krdpserver has, as far as the evidence goes, never completed initialization on this machine.
Next things I would check, all read-only:
1. The config the server reads. krdpserver reads ~/.config/krdpserverrc. In a working setup (reported in an openSUSE forum thread with the same server) that file names the TLS certificate and key under ~/.local/share/krdpserver/ plus a Users= line. Check the file exists and that the certificate paths it names exist and are readable. The KRDP README says the settings page sanity-checks certificate generation, so a missing or half-written cert is a plausible stall point.
2. See where it blocks:
strace -f krdpserver -u user -p pass 2>&1 | tail -40
The last lines before the hang usually name the resource it is waiting on - a D-Bus reply, a file, a socket.
3. Turn on Qt debug output:
QT_LOGGING_RULES='*.debug=true' krdpserver -u user -p pass
Qt’s logging rules are documented in the Qt QLoggingCategory docs; if krdp uses categorized logging, this shows the step it stalls on. If it stays silent, the strace from step 2 is the more informative of the two.
4. One hypothesis: the README says the settings page warns when the password manager is inaccessible, because KRDP stores the per-user RDP passwords there. Your blanked-wallet setup avoids an unlock prompt, but if the wallet daemon is not answering in that session, a startup call into it could block without a log line. The strace would show whether it is waiting on such a call. I have no README confirmation for this specific path, so treat it as speculation.
And one more data point, if you get to it: whether the hang also happens in a session started with a screen attached would separate “headless session” from “something broke between this morning and the reboot”.