Subject header that upsets Sup when run inside GNU Screen

[IPv2]

If Sup is run inside GNU Screen, then Sup can't display an email with a particular Subject header. Attempting to view the email in thread-view-mode immediately switches Sup into buffer-list-mode, sounds a terminal bell, and Sup also acts as if the user has input "c" to start to compose an email, followed by typing some garbage for the "To" recipient.

Possible security issue, since Sup acts as if it is receiving user input, but the origin is an email header?

Reproduce via a message with Subject containing "💜💙💚💛🧡":
Subject: =?utf-8?Q?=F0=9F=92=9C=F0=9F=92=99=F0=9F=92=9A=F0=9F=92=9B=F0=9F=A7=A1?=

Complete example email in attached issue-572-demo.txt

The shortest problematic email Subject that I've found so far is "💜" (plays terminal bell when email opened, i.e., when switching to thread-view-mode):
Subject: =?utf-8?Q?=F0=9F=92=9C?=

This isn't introduced by any recent commits - the same issue is also present in 0.22.1.

I haven't fully investigated yet, so I'm not sure at this stage whether this is a bug in Sup itself, or in an underlying library (e.g., ncurses), or even a bug or (mis-)feature of GNU Screen.

Reproduced when running Sup (version 0.22.1, 1.0, or 1.1-git-d3fbac13) inside GNU Screen (screen) (4.06.02 or 4.08.00), running in the default configuration (i.e., no .screenrc).

The issue does not occur when running Sup outside screen, or if running Sup in tmux.

[IPv2]

The behaviour also depends on the end user's terminal emulator.

For example, using xterm, there is no issue - though this might not be a particularly interesting test, because xterm replaces the emojis with the Unicode U+FFFD Replacement Character.

In above reproduction steps, gnome-terminal shows the issue.