Okay, I've looked over the code and I can point out the source of refreshing problem.
First, there is an unnecessary terminal.read() at the end of handle_keys(). It does not break things explicitly, but forces an additional keypress without any visual feedback after non-move action (e. g. inventory), which is wrong and makes behaviour non-intuitive (and probably making it look like setting fov_recompute not always works).
The menu() function uses layer #2 for its output and clears this layer at the start. I do not know if its intentional, but it also clears walls on the map (which also mostly uses layer #2). But neither of menu-popping actions set fov_recompute flag, therefore next render_all() skips drawing walls entirely and only objects are drawn. This leads to walls not being restored after any menu action until any move action (which does set fov_recompute) is taken.
A few other points:
1. Layering is excessive and inconsistent. Very distinct UI elements like map and menu dialog use the same layer which inevitably leads to collisions. On the other hand really similar elements like map and different objects use several different layers. Why do you even need to put the object in a different layer, whether it is fighter or not? >_<
2. Map drawing in render_all() selects a layer only under a certain condition inside the loop. This will put some of the tiles in whatever layer was selected before, which is fragile.
3. The menu() function uses libtcod.console_get_height_rect() to calculate a size of a string, while output is performed via BLT. This is not correct and is not guaranteed to work as they are totally separate functions of different libraries. BearLibTerminal has its own facilities to measure and auto-wrap text:
_, header_height = terminal.measure(header, width=width) # measure returns a (w, h) tuple
terminal.print_(x, y, header, width=width)
I suggest to clean up the layering. Layers are to help with logical grouping of output, not to make it messier >_<, there is no need to put everything in different layers. Probably just three will suffice: #0 for in-game objects (ground, walls, objects, etc.), #1 for basic UI (bars and statuses which are always over the map) and #2 for temporary popups like menus. It would also help to give some meaningful names to layers via constants.
As for TK_RESIZED, there is no easy way to introduce screen resizing with the current loop structure. Since user may resize the window in any moment, the application must be ready to handle the new size and update the whole screen in every game state and every dialog, e. g. in the inventory menu. Which will not work since modal menu() can't update the map layout. The easiest way would be to completely separate rendering from input processing so that the whole screen (map, general UI and dialogs) could be redrawn at any time, even during popup processing. But you'll probably have to rewrite from scratch the whole loop/dialog structure.