About posting the app itself to IPFS: this is what Sunodo deploy is doing too! But Sunodo currently just wraps the whole thing and posts the machine snapshot directly, instead of posting a docker container that is loaded dynamically into a standard Ubuntu machine (btw, I don’t think this part of loading from IPFS can ever be disputable on-chain right?).
I’m not sure I get the reason for your approach, which seems more complicated to me. Maybe you’re thinking about “bare-metal advance requests” too? (as described in the Lambda entry, in “4. Backend scalability”)
(I intended the text below to be a separate comment, but the forum only allows me to post 3 consecutive msgs 
)
All in all, do you see Rollups and Lambada converging? From my perspective, if we implement L1 pre-imaging (aka access to base layer state) via the dehashing device, then Rollups inputs become base layer blocks, as you suggested above. With Lambda, Rollups state after each input block could also be posted to IPFS, as you are proposing. And finally, to get side effects on L1 (such as asset withdrawals), we need claims and something like vouchers, which Rollups already implements.
If that’s what you have in mind, then I think we can achieve something very interesting in the short term! We could advertise a more flexible and modular-friendly approach from Lambada’s side (maybe with a more experimental tone), while we improve and converge the more production-ready Rollups side, adding in L1 pre-imaging and Lambda, and after that also reading inputs from Espresso, Celestia or other sources via the dehashing device. What do you think?