Incorrect back trace from `tasks -s ...`

humility dump: confusing-stack-trace.dump.tar.gz

Using this dump, the stack backtrace for the host_sp_comms task is:

% humility --dump confusing-stack-trace.dump tasks -sl host_sp_comms
humility: attached to dump
system time = 3491255
ID TASK                 GEN PRI STATE
15 host_sp_comms          3   5 notif: bit0(irq82)
   |
   +--->  0x240186e8 0x08078edc userlib::sys_recv_stub
                     @ /hubris/sys/userlib/src/lib.rs:334
          0x24018800 0x08078832 core::ptr::read_volatile
                     @ /rustc/4d6d601c8a83284d6b23c253a3e2a060fd197316/library/core/src/ptr/mod.rs:1468
          0x24018800 0x08078832 vcell::VolatileCell<T>::get
                     @ /crates.io/vcell-0.1.3/src/lib.rs:30
          0x24018800 0x08078832 stm32h7::generic::Reg<REG>::read
                     @ /crates.io/stm32h7-0.14.0/src/generic.rs:71
          0x24018800 0x08078832 drv_stm32h7_usart::Usart::check_and_clear_rx_overrun
                     @ /hubris/drv/stm32h7-usart/src/lib.rs:125
          0x24018800 0x08078832 main
                     @ /hubris/task/host-sp-comms/src/main.rs:40

We are definitely in sys_recv_stub, but that has not been called from core::ptr::read_volatile. This dump might have come from a build with slight deltas from debugging, but should be roughly equal to this commit. The highlighted lines show both the sys_recv_stub we're actually blocking in (line 52) and the check_and_clear_rx_overrun that humility thinks we're in (line 57).