Who is going to do that, some administrator? A bankruptcy trustee? No.
The best that could be achieved would be to build in some sort of rules like that into the scripts. No concrete method for doing that is proposed, but even if it were, it couldn't possibly handle all possible failures, since some if not all failures are by definition unanticipated. In the event that the state of a side chain were scrambled, there would just be no way to know who should be able to redeem.
For this reason, even the hint (or in some cases merely a rumor) of a problem on a side chain will lead to a run-on-the-bank scenario.
The whitepaper seemed pretty basic as most of them are. It's counter-productive to bog a reader down in minutia in such works.
The 'flash of insight' came, I think, with Maxwell's update on the various 'elements' and progress on them. Whether he outlined it specifically or whether I half invented it, I'm not sure. I had put my mind to the problem of incremental value pegging and mostly failed but I kinda started to see some of the possibilities when (I think) Maxwell was describing some of the time-lock primitives and such.
I never really appreciated (or even fully understood) some of the stuff about payment channels. To me it seemed like a lot of trouble and undesirable complexity for a rather narrow use-case. I can recognize the efficiency of controlling flows with start/stop messenging along a pre-defined channel (vs. a multitude of incremental value transactions) but it didn't (to me) translate much beyond paying for a porn movie until one finished their thing which can be difficult to predict ahead of time. I'm starting to glimpse how such efficiency could be used in more critical contexts, and in particular how such a thing could result in a default return of value absent occasional update pings.