Short version: Please try TERM=xterm nethack, it'll most likely do the trick.
Long version:
Please try out and examine the output of the script from my answer at Print a 256-color test pattern in the terminal.
The attribute you're talking about (\e[1m) has a legacy confusion whether it means bold, bright, or both. With extended 256-color palette appearing in pretty much all terminal emulators, and subsequently true color support appearing in some (including gnome-terminal), the tendency is shifted towards this attribute meaning bold. Obviously it's not intended to tamper with direct RGB colors, and it'd be problematic with the 256-color palette too (would there be a mapping among these indices, or would it result in out-of-palette colors?).
There are multiple ways to access the first 16 entries of the palette. The legacy escape sequences with the numbers 30–37 (foreground) and 40–47 (background) stand for the first 8. The foreground ones, if combined with the 1 (bold/bright) mode, still enable their bright counterparts for legacy compatibility reasons (e.g. for nethack to still look as it looked before... sigh).
The codes 90–97 (fg) and 100–107 (bg) stand for the next 8 palette entries which are the bright ones anyway.
The new 256-color palette escape sequences (38;5;0 – 38;5;255 for fg, 48;5;0 – 48;5;255 for bg) behave differently, though (following xterm's behavior): Here the 1 (bold/bright) attribute enables boldness only and does not change the color.
So, in your case, the difference is probably that your app used to emit the old-fashioned escape sequences, but now emits the new (256-color palette) ones which refer to the colors of the very same palette, the only difference is that mode 1 works differently: means bold only here rather than bold and bright.
This, in turn (walking backwards in the reasoning chain) is probably caused by the TERM environment variable defaulting to xterm-256color, rather than xterm as previously. Try reverting this variable and see how it effects your app.
Something that I don't understand without investigating (and will not investigate due to lack of time and interest): nethack seems to be using ncurses. ncurses does not allow the app to decide which kind of escape sequences to use, it only offers access to 256 colors, and it's ncurses's private business which escape sequence it uses for the first 16. In fact, as seen from the output of tput setaf and tput setab, in some weird syntax it encodes an if-else branch for the intervals 0–7, 8–15 and 16–255, that is, as far as I know, it is supposed to emit the legacy escape sequences for the first 16 colors, which in your case should mean that even with TERM=xterm-256color the behavior should not change compared to TERM=xterm. I'd let you further investigate from here given the input you received so far, e.g. use script to record nethack's output and examine with a text viewer to see which kinds of escape sequences it emits.
