refactor: migrate core DOM tree interfaces

[jderochervlk]

Tracking issue: #342

Summary

• migrate core node, element, range, traversal, selection, and character-data APIs onto DOMTree
• add focused interface modules including Attr, AbstractRange, StaticRange, CDATASection, and ProcessingInstruction
• move interface-specific operations out of the broad type modules

Temporary state

• the DOMTree types used here are still aliases to the old recursive definitions from refactor: introduce DOMTree compatibility foundation #301
• some shared option and helper types continue to come from DomTypes so this layer compiles independently
• refactor: remove DOM compatibility types #310 makes DOMTree concrete, relocates the remaining helpers, and deletes DomTypes

Review focus

• recursive type relationships and public method signatures
• completeness of each newly owning interface module
• absence of behavioral changes beyond type ownership

Verification

• npm run build
• npm test
• npm run format:check

[jderochervlk]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 08f7c6a1ec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[fhammerschmidt]

Is this so that completions actually show some contents?

[jderochervlk]

Yeah. It's a pattern that @tsnobip showed to me.

[jderochervlk]

Yes. The explicit private record keeps the inherited fields visible in editor completions; the type equation also preserves the intended identity with AbstractRange.t for this fieldless subtype. A stack-wide consistency audit is tracked in the parent issue follow-up checklist.