Fix incorrect node index handling and prevent duplicate node insertions in RemoteMutationObserver

[mfal]

This PR addresses an issue in RemoteMutationObserver where incorrect node indices led to improper insertion and removal of nodes, particularly in cases where multiple mutation records were processed in a single event.

In rare edge cases, nodes were being inserted multiple times on the host. Although the previous logic attempted to guard against this using addedNode.contains(node), it failed in scenarios where deeply nested replacements occurred. This check only considers direct descendants.

Changes Introduced:

• Replaced index-based node positioning with reference nodes.
• For removals, the removed node itself is now used as a reference.
• For insertions, the next sibling node (if available) is used as the reference; otherwise, the node is appended.
• Updated mutation processing logic to ensure correct order and prevent lost or incorrectly retained nodes.
• Added a test case in the kitchen-sink demo to verify the fix.
• Duplicate insertions are now prevented by checking on the receiver side if the node already exists under the parent before inserting. This avoids recursion and is both safe and performant.

Why this is needed:

• The previous implementation used numerical indices, which became unreliable when multiple mutations were applied at once.
• This caused elements to be inserted or removed at incorrect positions, leading to UI inconsistencies and, in some cases, crashes.
• Before checking for already added nodes was done by using the contains() method on the parent node, which only finds direct descendants.
• Instead of recursively checking all descendants in RemoteMutationObserver (which would add overhead), the solution was implemented on the receiver side.
• Before inserting a node, the host now checks if the node already exists under the expected parent and skips insertion if found.
• This avoids duplicate insertions with minimal performance impact.

These changes significantly improve the correctness and resilience of RemoteMutationObserver in complex mutation scenarios, while maintaining good performance characteristics.

Resolves #560

[mfal]

Hey @lemonmade! It's been quite a long time since I created this PR, so I would be very happy if you (or someone else) could keep an eye on this.

The MR does involve a big change, but I think it's all well structured and tested. There is also a test case that shows that the current implementation leads to errors. The linked issue also contains valuable information.

By the way, we have been running a fixed fork in a relatively extensive scenario for some time without any errors 😄

Thanks!