Dear Maintainer,

After a curses program using keypad(win, TRUE) is suspended with
Ctrl-Z (SIGTSTP) and resumed with `fg` (SIGCONT), the terminal is left
out of application keypad mode. The *first* special key pressed after
resume (e.g. an arrow key) is misreported: getch() returns a bare
KEY_ESCAPE (27), typically followed immediately by the escape
sequence's trailing bytes read back as ordinary characters, instead of
the expected KEY_* code. Every special key pressed *after* that first
one is reported correctly again.

This is directly reproducible with dialog(1) (also built from this
source package):

    dialog --menu "Test" 15 40 4 1 One 2 Two 3 Three 4 Four

  1. Press Down a couple of times: the highlighted item advances
     normally.
  2. Press Ctrl-Z, then run `fg` to resume. The menu redraws
     correctly.
  3. Press Down once: instead of moving to the next item, dialog
     receives a bare Escape and exits as if Cancel/Esc had been
     pressed.

Full root-cause analysis, a minimal C reproducer, and discussion with
upstream (Thomas Dickey) are on the bug-ncurses mailing list; see the
Forwarded: header above and the rest of the thread (msg00015.html
through msg00018.html in the same archive). Upstream has confirmed the
bug is still present in the current ncurses-snapshots sources and in
the latest 6.6-20260808 release; no fix has been applied yet as of
this writing. Filing this mainly for tracking, so it can be
updated/closed once upstream applies a fix and Debian picks up the
corresponding patch.