bug#45898: 27.1; wedged in redisplay again

[Devon Sean McCullough]

An elisp expression output a bigger list than expected so I hit m-< and
went out for a walk.  After four hours of 99% CPU, lldb backtrace shows

main → Frecursive_edit → recursive_edit_1 → command_loop →
command_loop.cold.1 → internal_catch → command_loop_2 →
internal_condition_case → command_loop_1 → read_key_sequence → read_char
→ redisplay_internal → redisplay_windows → redisplay_windows →
internal_condition_case_1 → redisplay_window_0 → redisplay_window →
compute_window_start_on_continuation_line → move_it_to →
move_it_in_display_line_to → gui_produce_glyphs → macfont_encode_char

If lldb forces read_char to return Qnil or redisplay_internal to return,
will Emacs crash immediately or survive long enough to save all buffers
or better yet continue working?

Would calling Fgoto-char(Fpoint_min()) from the lldb break immediately 
corrupt or crash Emacs?

        Peace
                --Devon

P.S.  If there exists a way to quickly and safely abort redisplay,
perhaps there should be a hook invoked when repeated keyboard-quit
has no effect, allowing experimentation into workarounds for this
apparently intractable redisplay problem?