By replaying the asciinema recording in a browser, I discovered that the issue was not on the record. This was a "display issue" caused by tmux. When viewing the asciinema (or connecting to the serial) outside of a tmux session, the log just continued and seems complete. But in tmux, even with the default config, it breaks. (just in case: I tested with&without tmux in xterm & KDE’s Konsole and bash & zsh)
Sorry for the potential disturbance here. Just in case, I will keep my question up in case anyone else hits the same issue and is helped by my answer, even if I think that is nearly impossible …
more explanation for super nerds
The issue happens because of this line being printed unescaped (that’s how the line was saved by asciinema, with spaces at the start truncated):
Mounting \u001b[0;1;39mdev-mqueue.mount\u001b…POSIX Message Queue File System...\r\n
The escape character \u001b is sent to invoke actions in the terminal emulator (called ANSI escape sequences. To summarize, e.g. \u001b[0;1;39m says "reset" (0), "toggle bold / increased intensity" (1) and "default foreground color" (39). The code afterwards should reset everything again, however systemd-journald asserted the original line as too long, so it truncated the original line by replacing the middle part with an ellipse (…) (this is explained here), leaving a single escape character alone.
While most terminal emulators (including Linux virtual tty) seem to be able to handle this mostly fine (at max a few characters are not printed), tmux continues parsing the escape code, resulting in 5 seconds where nothing is printed by tmux.