refactor: extract isNativeElement util (fix component-vs-HTML-tag misclassification)

[johanrd]

This PR is part of a broader a11y parity audit against jsx-a11y / vue-a11y / angular-eslint-template / lit-a11y.

Extracts a shared isNativeElement(node, sourceCode) util in lib/utils/is-native-element.js using html-tags + svg-tags + mathml-tag-names packages + scope analysis. Follows the lists-+-scope pattern @NullVoxPopuli established in #2689.

Problem

Two rules had a PascalCase-component misclassification: <Article role="button"> and <Article tabindex={{0}}> were flagged because the rules did node.tag.toLowerCase() and then looked up in a native-tag set.

Two other rules in master (template-no-arguments-for-html-elements, template-no-block-params-for-html-elements) already used the correct lists-+-scope approach but duplicated the same 6-line block inline. Four identical call sites past the rule-of-three threshold; the plugin's convention is utility-heavy (21 utils, 221 imports across 231 rules).

Changes

1. lib/utils/is-native-element.js — exports isNativeElement(node, sourceCode) + ELEMENT_TAGS. Returns true iff the tag is in the HTML/SVG/MathML lists AND NOT shadowed by a scope binding. 18 unit tests.
2. template-no-empty-headings — fixes misclassification when a PascalCase component contains text inside a heading.
3. template-no-invalid-interactive — fixes <Article role="button"> / <Article tabindex={{0}}> false positive.
4. template-no-arguments-for-html-elements — replaces inline copy with util call.
5. template-no-block-params-for-html-elements — replaces inline copy with util call.

Accepted false negatives (consistent with #2689)

Hyphenated custom-element tags like <my-element> aren't in any allowlist, so rules skip them. Their a11y contract is author-defined.

Scope-based detection can't help here: a hyphen isn't valid in JS identifiers, so an import like import './register-my-element' or import { MyElement } from 'my-element' doesn't correlate to the template tag my-element. Only PascalCase bindings (import MyElement from '...'; <MyElement />) work through scope. New rule-level tests pin the custom-element behavior in all 4 migrated rules.

Why lists + scope, not heuristics

A previous draft used a lexical heuristic (^[A-Z] / @ / this. / dot / ::). Rewritten after the definitive discussion in #2689 — a lowercase tag can legitimately be a component in strict mode when bound in scope, which heuristics can't detect. See that PR's review thread for the full reasoning.

Related

• #2689 — established the lists-+-scope pattern.
• ember-eslint-parser#189 — populates HBS block-param scope so the same util works for both gts and hbs.

Several other a11y rules on separate feature branches will adopt this util in follow-up PRs after they land.

Prior art

Each framework-specific a11y plugin handles the component-vs-native distinction in its parser layer, so no peer has a direct analog of this util. Verified per peer:

Plugin	Rule / util	Verified behavior
jsx-a11y	no equivalent rule	JSX syntax itself: PascalCase tag → component (uppercase first letter is language-level). No ambiguity because lowercase tag names can't be components in JSX. No equivalent util exists because no equivalent problem exists.
vuejs-accessibility	no equivalent rule	Vue's own component-registration system (components: { MyWidget } in options or <script setup> imports). Rules use Vue's AST node types (VElement vs VText) and Vue's resolver — not a separate heuristic.
@angular-eslint/template	no equivalent rule	Angular's selector system (attribute, element-name, or class selectors registered via @Component). Rules use Angular's template AST that has already resolved bindings at parse time.
lit-a11y	no equivalent rule	Custom-element registration via customElements.define(...) — inherently hyphenated lowercase tags. Rules work at the Lit-template level.

The closest analog in the plugin itself is #2689, which established the lists-+-scope pattern this util follows.