[100jinwoo001]

This PR fixes #2554 by intercepting the Tab and Shift+Tab keys when a TextInput or NumberInput is in readonly mode on GTK:

• In GTK, Gtk.Entry (and Gtk.SpinButton) emits gtk_widget_error_bell (system beep) when a key that would insert a character (like \t) is received while editable is False.
• In gtk/src/toga_gtk/widgets/textinput.py and gtk/src/toga_gtk/widgets/numberinput.py, when the widget is readonly and Key.TAB is pressed:
  • We navigate focus to the next (Gtk.DirectionType.TAB_FORWARD) or previous (Gtk.DirectionType.TAB_BACKWARD) widget via toplevel.child_focus (GTK3) / root.child_focus (GTK4).
  • We return True so the event is marked handled, preventing Gtk.Entry's default text insertion handler from triggering the error bell.
• Added towncrier note changes/2554.bugfix.md.

Under GTK, if a readonly text input loses focus as a result of keyboard input (pressing Tab), a system beep was emitted because GtkEntry treated Tab as an unhandled edit attempt before propagating focus.

Fixes #2554

PR Checklist:

• I will abide by the BeeWare Code of Conduct
• I have read and have followed the CONTRIBUTING.md file
• This PR was generated or assisted using an AI tool
  Assisted-by: ChatGPT

[freakboy3742]

Is this intentionally still in draft status? It seems to be passing CI, so it's unclear if you're planning to do more work here.

[freakboy3742]

This is a relatively straightforward fix; the problem with the PR is that it is untested.

This won't show up as a coverage gap because there's no "branch" involved here - we need to add a testbed case for giving focus to a readonly widget (gated on whether each platform allows a readonly widget to accept focus).