iOS 26 regression? `enablesReturnKeyAutomatically`'s disabled return key re-enables after switching keyboard planes (letters ⇄ numbers)

On iOS 26, the auto-disabled state of the return key driven by UITextInputTraits.enablesReturnKeyAutomatically is lost whenever the user switches keyboard planes (letters ⇄ numbers/symbols via the 123/ABC key). The key renders as enabled even though the text is still empty. Tapping it does nothing (the disable is still honored functionally), but the visual state is wrong until the next re-evaluation.

This is a regression: iOS/iPadOS 17 behaves correctly (verified on iPadOS 17.7). It also reproduces in Safari's own address bar on iOS 26, so it does not appear to be app-specific.

Minimal reproduction (stock UIKit, no custom code):

let textField = UITextField()
textField.enablesReturnKeyAutomatically = true
// present it, focus it, leave it empty

1. Focus the empty text field — the return key is disabled (correct).
2. Tap 123 to switch to the numeric plane → the return key becomes enabled (incorrect — text is still empty).
3. Type one character and delete it (still in the numeric plane) → the key becomes disabled again (correct).
4. Tap ABC to switch back to the letters plane → the key becomes enabled again (incorrect).

Safari reproduction (stock behavior, physical device):

1. Open Safari on iOS 26, focus the address bar, and delete all text → the Go key disables (correct).
2. Switch to the numeric plane → the Go key re-enables (incorrect). Tapping it gives haptic feedback but performs no action — the disable is still honored functionally; only the rendered state is wrong.
3. Still in the numeric plane, type something (e.g. 123.456) and delete it all → the key correctly disables again (the hasText round-trip re-syncs it?)
4. Switch back to the letters plane → the key wrongly re-enables again. The glitch triggers on plane switches in either direction.

Additional observations (from our app's UITextFields — the same enablesReturnKeyAutomatically mechanism, but driven by a stricter text-validity rule than plain empty/non-empty, which makes the desync observable in more states):

• Two further workarounds restore the correct state after the glitch: switching the keyboard language (globe key), or changing the text and then tapping anywhere in the text field.
• A text change that does not flip the hasText state, without a follow-up tap, does not repaint the key.
• The pattern suggests that the keyboard rebuild triggered by switching planes defaults the return key to enabled without consulting the text state, and that the keyboard otherwise repaints the key only when the hasText answer transitions, or on input-session changes (tapping into the field, switching keyboard language).

Environment: all reproductions and verifications were done on physical devices, not simulators — reproduced on an iPhone SE (iOS 26.5.2) and an iPad Pro 12.9" 4th gen (iPadOS 26.4.2); not reproducible on an iPad 6th gen (iPadOS 17.7.10).

Is this a known issue, and is there a supported way to force the keyboard to re-evaluate the return key state after a plane switch?