Warn when NaN is passed as an aria-* attribute value

[starboyvarun]

Summary

aria-* attributes currently bypass the NaN check in ReactDOMUnknownPropertyHook because they return early (line 97-99 of that file) before the check is reached. When a NaN number flows through, the DOM stringifies it to the literal string "NaN", which is invalid for every ARIA attribute type and silently breaks accessibility.

This is a common pitfall when a computed numeric value is derived from user data or state that can be undefined/null:

// e.g. items.findIndex(...) returns -1 → some derived math → NaN
<div aria-valuenow={computedValue} />  // renders aria-valuenow="NaN" — silent bug

Changes:

• ReactDOMInvalidARIAHook.js — extend validateProperty to accept the prop value and add a NaN check for valid, correctly-cased aria-* attributes. Mirrors the warning message already used by ReactDOMUnknownPropertyHook for non-aria attributes.
• ReactDOMInvalidARIAHook-test.js — three new test cases: NaN on a numeric aria attribute (aria-valuenow), NaN on a string-type aria attribute (aria-label), and no false-positive for valid integers.

Test plan

• yarn test ReactDOMInvalidARIAHook — all tests pass (new + existing)
• Existing tests unaffected — only the validateProperty signature changes (internal)

[liufang88789-ui]

Nice fix. The NaN → "NaN" stringification in the DOM is an insidious silent bug, especially since computed numeric values (like derived state from findIndex returning -1) flow into aria-* props frequently.

The placement is right — checking in validateProperty before the return, and mirroring the existing error message pattern keeps it consistent with the rest of the hook. Passing props[key] as the third argument is minimal and clean.

One edge case worth considering: what about Infinity? It has the same stringification problem ("Infinity" is equally invalid for aria attributes), though it's less common in practice. Not necessarily a blocker for this PR, just something to keep in mind.