Change Proposal: Restrict keystrokes in `NumberInput` to characters valid for the selected `numberMode`

Start at NumberInputText and trace how its underlying TextField receives keystroke and paste input, alongside the existing whole-string validation of numberText. Check how numberMode selects the allowed characters and how rejected input can provide a visual or aria-live signal. Done means filtering follows the four stated modes, mid-entry signs remain typeable where required, and whole-string validation is unchanged.

What is being proposed?

As discussed in Atlas #143, the NumberInput currently accepts any keystroke into the underlying TextField and only flags invalid content after the fact. A user can type letters, symbols, multiple decimal points, etc., and only discovers the problem from the "Invalid input" helper text.

Proposal: filter keystrokes/paste input as they happen, so only characters that could ever be valid for the active numberMode are accepted:

• Natural: 0-9
• Integer: 0-9, +, -
• Floating: 0-9, +, -, .
• Scientifc: 0-9, +, -, ., e/E

Why is this needed?

• A natural mode field currently lets a user type -5, rejecting it only after the fact. Blocking - at keystroke time prevents that error state from being reachable at all.
• For integer/floating/scientific, - must stay typeable (including mid-entry, e.g. - alone or -1.).
• Filtering at input time avoids the most common invalid keystrokes (letters, symbols) ever reaching numberText. It doesn't catch positionally-invalid strings like 12-3 or 1.2.3, and those still rely on the existing whole-string validation on blur/submit.

Known limitations

Dropping a keystroke silently (character never appears) gives no feedback to screen reader users, unlike the current visible error state. The implementation should pair the filter with some non-visual signal so this isn't a regression for assistive technology users.

What will change?

NumberInputText filters out characters that are not in the allowed set for the active numberMode before they're accepted. When a keystroke is rejected, the field gives a lightweight signal that something happened (e.g. a brief visual cue, and an aria-live="polite" announcement so screen reader users aren't met with silence). Whole-string validation is unchanged. No new props required.

Interface changes (if any)

None required by default. Optional escape hatch if any keys are desired.

Breaking change?

• Yes
• No

Next steps

A maintainer will review this issue.
If accepted, it will be marked as accepted and a PR may then be opened.