Correct DOM constructor, narrowing, and SVG className contracts #391

Part of #382 — v1.0.0 alpha readiness.

Confirmed type-contract problems

1. src/window/CustomElementRegistry.res:5-L10 accepts DOMTree.htmlElement for constructor. Native customElements.define() requires a class/constructor function, not an element instance. Use the existing custom-element constructor type, already used by adjacent registry methods.
2. src/dom-nodes/Element.res:98-L103 returns unconstrained Null.t<'e> from closest. A caller can claim the result is an input when the selector actually matches a div, bypassing checked classification.
3. src/dom-nodes/DOMTree.res:195-L197 exposes className as string through broad Element/SVG inheritance. Native SVG uses SVGAnimatedString, so ordinary string operations are unsafe.

Review Chromium probes confirmed constructor-vs-instance registration behavior, the actual ancestor returned by closest, and SVGAnimatedString representation. These are type-contract defects, not requests for new API coverage.

Acceptance criteria

• Register a real custom-element class through the corrected binding and verify construction; reject an element instance at compile time.
• Return a broad element from closest, requiring the existing checked classifiers for narrowing to a specific element type.
• Reject direct unrelated-element assignments from closest in a negative compile fixture.
• Choose a sound representation/accessor boundary for HTML versus SVG className; verify both direct SVG access and SVG values returned by broad selectors.
• Preserve practical class-list/attribute workflows and document any alpha API changes.
• Add browser regressions for all three contracts.

Related context: #237. This is a correctness fix, not a reopening of the entire package-structure refactor.

Coordination

Use the regression infrastructure in #383. Source fixes can be developed in parallel, but this issue should close with executed regression coverage, not only a successful compile.