BUGFIX: template-no-unsupported-role-attributes — honor aria-query attribute constraints

[johanrd]

• Premise 1: aria-query's elementRoles map encodes element → implicit-role pairings that depend on attribute state. Each entry lists attributes that must be set, undefined, or match a specific value.
• Premise 2: Our getImplicitRole helper returned the first entry whose tag name matched, ignoring the attribute constraints on subsequent entries.
• Conclusion: Several common elements got the wrong implicit role.

Concrete consequences of the old logic:

HTML	Implicit role we returned	Correct implicit role
<input type="text"> (no list)	combobox	textbox
`<input type="email	tel	url">(nolist`)
<input type="password">	button	none (unmapped by aria-query, matches HTML-AAM)

The first two block valid usages involving attributes that textbox supports but combobox does not — notably aria-placeholder (covered by the new tests) and aria-multiline. Both textbox and combobox list aria-required in aria-query 5.3.2, so that attribute is not the concern here. The third row is arbitrarily wrong — there's no reason a password input should ever be treated as a button. <input type="password"> being left unmapped is consistent with HTML-AAM, which assigns it "No corresponding role."

Fix: walk every elementRoles entry whose name matches the tag; evaluate each attribute spec (checking constraints: ["set"], constraints: ["undefined"], and required values); pick the entry with the most attribute constraints satisfied.

Eight new valid tests cover the textbox/password paths. One existing test updated: <input type="email" aria-level={{this.level}} /> now maps to textbox in the error message; a sibling case with list="x" covers the combobox path.

Prior art

Plugin	Rule	Verified behavior
jsx-a11y	role-supports-aria-props	Computes implicit role via per-element lookup tables under src/util/implicitRoles/ (e.g. a.js checks for href before returning "link"); then validates that every aria-* attribute is in the role's supported-props list from aria-query.
vuejs-accessibility	no equivalent rule	vue-a11y's aria-props rule only validates that attribute names beginning with aria- are known ARIA attributes (via aria.has(lowered)); it does not compute implicit roles or check role↔prop compatibility.
@angular-eslint/template	no equivalent rule	angular-eslint's valid-aria validates ARIA attribute names and literal values against aria-query's definitions; it does not resolve implicit roles from element + attributes, so the role-supports-props check does not apply. role-has-required-aria is the inverse check (role → required props), not role → supported props.
lit-a11y	role-supports-aria-attr	Only reacts to an explicit role= attribute (Object.keys(element.attribs).includes('role')); does not compute an implicit role from tag + attributes, so the implicit-role false positive does not arise.

Audit fixture

Translated peer-plugin test fixture at tests/audit/role-supports-aria-props/peer-parity.js documenting our rule's behavior relative to jsx-a11y and lit-a11y. Not wired into the default test run.