Bootloaders have to reside in upper flash memory so that they can change lower memory without damaging themselves. So you can't just add code to your sketch to support re-flashing. That also means the entire RF12 driver (or at least a minimal version of it) has to fit into that upper flash area.
A second issue which needs attention, is that an upload must complete and be 100% correct, so you need a robust error-correcting protocol over which to send the new upload. And do a CRC check before exiting the boot loader.
I've explored these issues in the past and will have another go at them, now that I have a good test setup.
The 1% rule would indeed slow the uploads a lot, it will take several minutes in fact. There are a couple of ways to avoid that:
ignore the 1% rule for 868 MHz, just hijack the band and use it 100% for a couple of seconds
use 433 MHz for these uploads (range may not be an issue, if uploads are always done at close range)
work with an interpreter, and only upload the interpreted code, which is probably much smaller
split the code into custom app and runtime, and leave the runtime intact - just upload the custom code
A third issue which needs some thought is the workflow: how to go from a modified sketch to an updated remote node.
All the above seems doable, but it'll take some work to get all the pieces 100% working and in place. An unreliable over-the-air upload is probably not very useful, since you'd just end up re-trying and wasting a lot of time.