winsch()/insch() ignores the locale for an 8-bit character, unlike waddch()

ncurses 6.6.20251231, wide-character build (libncursesw), Linux/glibc.
(The code path is present in every wide build I checked, ncurses 5.9 
through 6.6.)

On a wide-character build, inserting a printable 8-bit byte > 127 with
winsch()/insch() stores the byte as a code point directly, without 
converting it
through the locale, whereas waddch() with the same byte runs the normal 
mbtowc
conversion.  So under a non-Latin-1 8-bit locale addch() decodes the 
byte and
insch() does not.

Under en_US.ISO-8859-15, byte 0xA4 is EURO SIGN (U+20AC): addch(0xA4) 
stores the
euro, but insch(0xA4) stores U+00A4 instead -- a different character.  For a
Latin-1 locale the bug is invisible, since there the byte equals the 
code point
(0xA4 -> U+00A4 either way), which is presumably why it has gone unnoticed.

   #include <locale.h>
   #include <curses.h>
   #include <stdio.h>

   int main(void) {
       char a[4] = {0}, b[4] = {0};
       setlocale(LC_ALL, "");
       initscr();
       addch(0xA4);                 /* addch decodes the byte via the 
locale */
       mvinsch(1, 0, 0xA4);         /* insch under test */
       mvwinnstr(stdscr, 0, 0, a, 1);
       mvwinnstr(stdscr, 1, 0, b, 1);
       endwin();
       fprintf(stderr, "addch(0xA4): winnstr=0x%02X\n", (unsigned 
char)a[0]);
       fprintf(stderr, "insch(0xA4): winnstr=0x%02X\n", (unsigned 
char)b[0]);
       return 0;
   }

   $ cc repro.c -o repro -lncursesw
   $ TERM=xterm LC_ALL=en_US.ISO-8859-15 ./repro

winnstr() reads each cell back as a locale byte.  Expected, with insch 
matching
addch, is 0xA4 for both.  Actual:

   addch(0xA4): winnstr=0xA4         (the euro, read back correctly)
   insch(0xA4): winnstr=0x20         (a blank: U+00A4 is not in 
ISO-8859-15, so
                                      the inserted euro was lost)

(Use addch(0xA4), not addstr("euro"): a UTF-8 source literal is misread 
under an
8-bit locale.)

In ncurses/base/lib_insch.c, _nc_insert_ch() handles a printable 8-bit 
byte with
a fast path that builds the cell straight from the byte:

       if (... (isprint(ch8) || ...)) {
           ...
           SetChar2(wch, ch);          /* byte used directly as the code 
point */
       }

The locale conversion, _nc_build_wch() (mbtowc), is only reached in the 
trailing
"else" branch, for a byte that is not isprint() in the current locale.
waddch()/wadd_wch() route every non-ASCII byte through _nc_build_wch(), so
addch() decodes 0xA4 to U+20AC while insch() short-circuits to U+00A4.  
A fix
would let the wide build take the _nc_build_wch() path for an 8-bit byte 
in the
insert case too (the isprint() fast path is fine for ASCII).

This is the write-side companion to the winch()/inch() locale issue reported
separately: there winnstr() decodes a cell via the locale while winch() 
returns
the truncated code point.  Both come from the legacy 8-bit chtype API 
treating a
byte inconsistently across functions on a wide build.