Let's just step back for a moment, what are the common reasons for needing a recovery of some sorts?
- flashed a new firmware that doesn't even boot (or misses/ misconfigures crucial components, as in the network)
to fix this, you need to get the bootloader to save your bacon - but OpenWrt doesn't provide the bootloader, so there's nothing you really can do within OpenWrt, even less as you don't know in advance that you're going to need recovery - firmware is fine, but a someway wrong configuration has been applied or that the overlay has been compromised (as in overlay full)
this means you can't trust the overlay to be consistent, nor that you can even mount it in the first place (it may no longer be readable)
If you can find a fix for the former, you no longer need to care about the later.
But these problems remain (regardless of which of the two you're going to tackle):
- you need to find some way to reliably trigger the recovery, avoiding false positives, but also not relying on the potentially broken installed firmware and its potentially misconfigured overlay
- you need some way to connect to recovery environment, ideally to write a new firmware (akin to push-button tftp) or at least to OpenWrt's failsafe environment (this would only guard against very simple configuration issues)
- you may need to find a way to preconfigure your recovery environment to some extent (e.g. wifi credentials), so something like imagebuilder an custom uci firstboot scripts (not really point and clicky)
I have a problem finding any reliable approach to the former, but I fundamentally miss any chance of doing the later. The only conceivable approach would be over wired ethernet, as wireless is way too heavy for bootloader based approaches - even for an OpenWrt based failsafe like environment.
EDIT: and making all of this kind of generic, to work on multiple (~all) different devices…