@schneider, this is for you :) I think I've managed to figure out how to solve the lockup you observed in a way that's both compatible with the old (non-masking API calls) and new (irq-masking API calls) schemes. Please take a close look though, I'm a bit scared that I might have again missed something here...
Commit 7fb48178 ("feat(lifecycle): Allow core 1 to disable interrupts during API calls") is the important part. The commit message explains the details:
When interrupts are disabled during API calls on core 1, we can only trigger a core 1 reset when there is no API call ongoing. This means that the lifecycle machinery needs to allow any running API calls to complete before it has a chance to see its reset interrupt delivered.
This is complicated because we cannot synchronize on core 1 triggering an API call - the best we can do is stop the dispatcher, check whether our reset interrupt was delivered, and if not, give it another chance to process an API call.
Additionally, "give it another chance to process an API call" means that the IDLE task must run, because this is currently a prerequisite to scheduling the dispatcher (see API call mechanism). The only way to facilitate this is with a sleep that is long enough that it will eventually let core 0 go idle. It seems that an 8 tick delay does the job quite fine.
Thus, implement a busy loop which provides the above requirements and with that makes Epicardium prepared for payloads which perform API calls with interrupts disabled.
Ontop, I then added the critical section in the API caller code in commit 92741109 ("feat(api-caller): Hard-disable all IRQs during API calls"). Note that I am currently disabling absolutely everything here - we might want to revise this in the future to allow some kind of "NMI execution stage" which can still run but then cannot call API calls. Doing this would break the sleep-usecase again, though...