How about this for another idea...
If you have overrun the stack, an ISR will still execute (provided there is physical RAM there, and if there isn't, it will still get
entered provided that writing to nonexistent RAM doesn't trigger a trap) even if it is corrupting memory.
It will also return OK but we aren't necessarily interested in that.So how about checking the SP value at the start of any regular (e.g. 1kHz tick) ISR and if found below the stack, take some action e.g. somehow report it, and then reboot the CPU.
In an embedded system, if the stack has overflowed then you are already buggered, there is no meaningful error recovery anyway since RAM is already corrupted, and in most products there is no way to report the error anyway

FWIW I have found RTOS stacks to be a far bigger issue than the general stack which is not normally big and just services pre-RTOS-start code, and ISRs. I have 8k for it and only about 1k is ever used. RTOS stacks are a much harder issue because you have one per task and you have to somehow make sure each one is big enough. In most cases the only way is to run the product for a long time and see how far each (custom-prefilled) stack area has been overwritten.