Fixes #989.

Problem

CharacterData stores text in two plain properties — data and nodeValue — that are not kept in sync under direct property assignment:

const text = doc.documentElement.firstChild;
text.nodeValue = 'Changed';
text.data;  // still 'Hello'
new XMLSerializer().serializeToString(doc);  // '<root>Hello</root>'

XMLSerializer reads node.data, so changes via nodeValue are silently lost on serialization. The reverse (node.data = 'text' leaving nodeValue stale) also applies.

Built-in mutation methods (appendData, replaceData, splitText) are unaffected — they explicitly assign both properties. The issue is only with direct property assignment.

Fix

Add Object.defineProperty accessors for data and nodeValue on CharacterData.prototype, inside the existing try { if (Object.defineProperty) { ... } } block:

• data is the canonical store (backed by _data); the getter normalizes null/undefined to '', and the setter updates length for string assignments
• nodeValue is a thin alias that delegates to data

This follows the same pattern already used in the codebase for textContent and LiveNodeList.length.

Existing mutation methods are unchanged — their this.nodeValue = this.data = text assignments now flow through the setters, which is redundant but correct and avoids any behavior change for environments without Object.defineProperty.

Tests

New tests in test/dom/character-data.test.js, covering:

• nodeValue assignment updates data and length (Text, Comment, CDATASection)
• data assignment updates nodeValue and length (Text, Comment, CDATASection)
• XMLSerializer output reflects both assignment paths per node type
• null values stay in sync between data and nodeValue
• replaceData and appendData still work correctly
• cloneNode preserves data/nodeValue/length
• splitText preserves sync on both halves
• ProcessingInstruction nodeValue/data sync and serializer output

Spec reference

WHATWG DOM Living Standard §4.10 — for CharacterData nodes, the nodeValue getter and setter must be equivalent to data.

Environments without Object.defineProperty keep existing behavior; this PR does not add a separate fallback.

Related to #42.