[bdbarnett]

On MicroPython a failed LVGL assertion spun in while(1) with the scheduler locked, so a board's USB serial and WebREPL went silent until a power cycle. Now the MicroPython port provides lv_micropython_assert_failed() (weak in lv_conf.h, like the CircuitPython hook), which raises RuntimeError("LVGL assert failed in lv_inv_area (lv_refr.c:286)"). LVGL's log is off in these builds, so the function, file and line are how to find the assertion's message. CircuitPython and the CPython wheel are unchanged.

Where the exception lands decides what happens next. Inside a Python callback (a flush callback, an event, a timer), the binding's callback wrapper already catches exceptions, prints them and returns to LVGL, so the call that asserted is abandoned and LVGL finishes its pass. This is the case in the issue: Python code changing a widget while LVGL renders. With no Python callback in between, as when an allocation fails inside a render, the exception unwinds out of LVGL to whoever called lv.timer_handler() or lv.refr_now(). Before raising, the handler clears lv_timer_handler()'s running flag and each display's rendering flag, because they'd otherwise stay set and survive a soft reset. To tell the two cases apart, the generated binding exports mp_lv_nesting_depth(), the callback depth it already keeps. Both generated C files are regenerated, and ./regenerate_all.sh --check matches. I didn't add a separate print before the raise: the exception already shows up wherever it's caught, so a second copy would only repeat it. If no Python frame at all can catch it, nlr_jump() ends in the port's own nlr_jump_fail().

I checked this on a unix build with this branch. First, a flush callback that calls label.set_text() mid-render. The previous build hung (killed by timeout after 15 s). This build prints the RuntimeError from inside the callback, lv.refr_now() returns, and a second refresh flushes. Second, with the heap filled so that lv_draw_add_task() fails mid-render: the previous build hung, and this build raises out of lv.timer_handler(); once the heap is freed, the next refresh draws two flushes. With the flag repair taken out (a planted build), every later invalidation raised lv_inv_area again, which is why it's there. An RPI_PICO2 build compiles and links the handler (CMake path, compressed error text). pytest ports/micropython/tests tests/test_nesting_export.py tests/test_generation_tools.py passes.

I didn't run this on a board, and I didn't check every LVGL assert. An assert that fires halfway through changing a linked list can still leave that object inconsistent, but the board stays reachable.

Fixes #12