Parser: pre-existing issues in adoption agency algorithm (sanitizer and intended parent) #13093

While reviewing #12758 (stream*HTML*), we identified several pre-existing issues in the HTML parser's adoption agency algorithm (particularly its interaction with parser-level sanitization and custom element registries, as well as intendedParent resolution).

Filing these separately so they can be addressed independently of #12758:

1. furthestBlock retains a null custom element registry when reparented out of a removed formattingElement:
   When an element is created inside an ancestor whose sanitizer action is "Remove", create an element for a token sets its custom element registry to null. If the adoption agency algorithm later reparents furthestBlock (via lastNode) into commonAncestor because formattingElement was removed, furthestBlock's custom element registry remains null even though it is now in the kept subtree, preventing subsequent descendant elements from looking up a registry via their intended parent.

2. furthestBlock's children briefly enter the target tree when formattingElement is "Remove":
   Step 4.14 inserts lastNode (furthestBlock, along with its existing children) at the appropriate place for inserting a node given commonAncestor before steps 4.15–4.16 create newElement (which is not inserted when formattingElement's sanitizer action is "Remove") and move furthestBlock's children into newElement. As a result, when commonAncestor is in the live tree, furthestBlock's children are momentarily inserted into the target tree (triggering insertion steps, connectedCallback, iframe loading, or script preparation) even though they end up inside the removed newElement.

3. Clones created in the inner loop below a removed ancestor get the live document and custom element registry:
   In the inner loop (step 4.13.6), create an element for a token is always called with commonAncestor as intendedParent. If an outer cloned formatting element in the inner loop (or formattingElement itself) has a sanitizer action of "Remove", inner clones whose own sanitizer action is "Keep" still receive commonAncestor's document and custom element registry (allowing synchronous custom element constructors to run in the live document), even though they end up appended to a removed ancestor subtree.

4. Inner loop passes commonAncestor directly as intendedParent:
   Step 4.13.6 passes commonAncestor directly as intendedParent to create an element for a token, rather than the target parent of the appropriate place for inserting a node given commonAncestor. When commonAncestor is a <template> element or triggers foster parenting, the intended parent used during cloning diverges from normal parser insertion (insert a foreign element), affecting nodeDocument and custom element registry lookup.