docs(template-no-invalid-interactive): fix WAI-ARIA 1.2 section citations

The previous edit labelled the role-fallback citation as '§4.1 "Role Concepts"'
(no such section title) and pointed at #roles_categorization (that anchor is §5.3
'Categorization of Roles' — the widget/landmark/document-structure taxonomy,
not role parsing). The token-list fallback semantic is defined in §8.1 'Role
Attribute' (#host_general_role): 'The first name literal of a non-abstract
WAI-ARIA role in the list of tokens ... defines the role.'

Also drop the phantom '§4.6' label — §4 has only 4.1/4.2/4.3. The conflict
resolution subsection lives under the presentation role in §5.4; keep the
existing anchor but label it by its actual heading.

Author: johanrd

docs/rules/template-no-invalid-interactive.md

@@ -51,13 +51,13 @@ Examples of **correct** code for this rule:
 An element opts out of this rule's handler-on-non-interactive check in two cases:
 
 - **`aria-hidden="true"`** (including valueless / empty / `{{true}}` / `{{"true"}}` forms) — the author has explicitly removed the element from the accessibility tree, so a "non-interactive element with handler" is moot; AT users won't encounter it either way. Explicit `aria-hidden="false"` / `{{false}}` still flags.
-- **`role="presentation"` / `role="none"`** — the author asserts the element is decorative. We accept `role="presentation"` and `role="none"` (case-insensitive, first-token of a space-separated role list) — a deliberate superset of [jsx-a11y's exact-match `isPresentationRole`](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/src/util/isPresentationRole.js) for consistency with [WAI-ARIA 1.2 §4.1 "Role Concepts"](https://www.w3.org/TR/wai-aria-1.2/#roles_categorization) role-fallback semantics (first recognized token wins).
+- **`role="presentation"` / `role="none"`** — the author asserts the element is decorative. We accept `role="presentation"` and `role="none"` (case-insensitive, first-token of a space-separated role list) — a deliberate superset of [jsx-a11y's exact-match `isPresentationRole`](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/src/util/isPresentationRole.js) for consistency with [WAI-ARIA 1.2 §8.1 "Role Attribute"](https://www.w3.org/TR/wai-aria-1.2/#host_general_role) role-fallback semantics (first recognized token wins).
 
 The valueless `aria-hidden` case (e.g. `<div aria-hidden>`) is [genuinely contested](https://www.scottohara.me/blog/2018/05/05/hidden-vs-none.html) — jsx-a11y, vue-a11y, axe-core, and the WAI-ARIA spec take four different positions on whether it counts as "hidden". This rule leans toward fewer false positives: flagging a handler on an author-decorated element creates friction more often than it catches real bugs.
 
 ### Related checks outside this rule's scope
 
-- **`role="presentation"` on focusable elements** — per [WAI-ARIA 1.2 §4.6 Conflict Resolution](https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none), browsers ignore `role="presentation"` on focusable elements. [axe-core's `presentation-role-conflict`](https://dequeuniversity.com/rules/axe/4.10/presentation-role-conflict) flags this pattern as an authoring error. This rule does not detect the conflict: the escape hatch only affects elements that would otherwise be considered non-interactive, so a non-interactive element decorated with `role="presentation"` is silently exempted even if it is focusable via `tabindex`. Natively-interactive elements such as `<button>` / `<a href>` are already recognized by `isInteractive(node)` independent of the escape hatch; the rule doesn't report them in the first place, and it doesn't enforce presentation-role conflict checks. If you want to catch that authoring error itself (role=presentation on a focusable element, which has no effect at runtime), layer axe-core or a dedicated rule on top.
+- **`role="presentation"` on focusable elements** — per [WAI-ARIA 1.2 "Presentational Roles Conflict Resolution"](https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none) (a subsection of the `presentation` role in §5.4), browsers ignore `role="presentation"` on focusable elements. [axe-core's `presentation-role-conflict`](https://dequeuniversity.com/rules/axe/4.10/presentation-role-conflict) flags this pattern as an authoring error. This rule does not detect the conflict: the escape hatch only affects elements that would otherwise be considered non-interactive, so a non-interactive element decorated with `role="presentation"` is silently exempted even if it is focusable via `tabindex`. Natively-interactive elements such as `<button>` / `<a href>` are already recognized by `isInteractive(node)` independent of the escape hatch; the rule doesn't report them in the first place, and it doesn't enforce presentation-role conflict checks. If you want to catch that authoring error itself (role=presentation on a focusable element, which has no effect at runtime), layer axe-core or a dedicated rule on top.
 - **Click handler on a non-focusable decorated element** — e.g. `<div role="presentation" {{on "click"}}>`. Our escape hatch silences this by design (jsx-a11y-compat). [axe-core's `click-events-have-key-events`](https://dequeuniversity.com/rules/axe/4.10/click-events-have-key-events) is the complementary check. If you want strictness, layer it on top.
 
 ## Options