After some detective work, here is the js that causes the infinite loop.
It creates two nodes, ft and fg, uses ft.innerHTML to put some nodes beneath ft,
then has a while loop that, I assume, moves the nodes from ft to fg.
Here's the code, then more thoughts below.

var rid=oio.at_ei,fg=document.createDocumentFragment(),ft=document.createElement('div');
ft.innerHTML='<'+'div class="'+oio.at_ec+'" id="'+rid+'" style="'+oio.at_es+'">&nbsp;'+'<'+'/div'+'>';
while(ft.firstChild)fg.appendChild(ft.firstChild);
document.body.insertBefore(fg,document.body.childNodes[0]);

Ok, so the generated html looks like this.

<div class="MBoxAdMain gp-ui" id="sponsoredwellcontainertop" style="position:absolute;display:block;">&nbsp;</div>

Running through innerHTML, that creates a node under ft.
All good so far.
Then comes the while loop, and the only way this isn't an infinite loop is if appendChild removes the node first from wherever it is, then appends it.
I've been talking about this on the edbrowse side, in our own tree of nodes, but here it is on the js side, strictly within dom, and it's the same issue.
I think this is not just compelling evidence, but a smoking gun.
Even if it doesn't say so in the spec, appendChild and insertBefore should remove the child from wherever it is first, then put it beneath the new node.
Then the while loop above simply moves all the children from ft to fg.  Zip zap.

I'm going to think about this for a bit, cause if I just start writing code I'll screw it up, but I'm pretty sure I understand the problem now.
I just need to fix it with a small amount of code, and not breaking anything else.
I imagine if I fix it on the js side, by issuing a remove when necessary, before the append, then all those actions will carry over to the edbrowse side in our sideEffects, and I won't have to change any code over there, it will just all work.

Karl Dahlke