Model mounted VDOM text nodes as @dom.Text instead of @dom.Element

[yorkin-bot]

Summary

The client VDOM currently models mounted text nodes as elements:

priv enum INode {
  // ...
  Text(String, @dom.Element)
}

The underlying browser object is a DOM Text node (nodeType === 3), not an Element (nodeType === 1). This type mismatch is currently hidden by the DOM binding tracked in #132, where Document::create_text_node is declared as returning Element.

Runtime impact

Hydration exposes the mismatch directly. Once a VNode::Text matches an existing DOM text node, converting it with node.to_element().unwrap() must fail because to_element only accepts nodeType === 1.

An unchecked JS cast can make the code compile, but it leaves the VDOM with an @dom.Element value whose runtime object is still a DOM Text. Any future Element-only operation on that field can therefore fail at runtime.

Expected model

• Document::create_text_node returns the existing @dom.Text wrapper (tracked by DOM bindings expose nullable and non-Array browser values with unsound types #132).
• INode::Text stores @dom.Text, not @dom.Element.
• Hydration narrows an existing node with to_text().
• Text-node code only relies on the shared IsNode operations.
• No unchecked @js.Value cast is needed to claim an SSR text node.

Suggested regression coverage

• Hydrate an existing matching text node and verify the same DOM node is retained.
• Hydrate mismatched text content and verify its nodeValue is corrected in place.
• Diff a hydrated text node after hydration.
• Verify Element-only APIs are not available on the mounted text-node field.
• Regenerate and review the DOM package interface after correcting create_text_node.

Related DOM binding issue: #132.