Windows: `text-field%` clips top of glyphs when display scaling >100% (after 2nd character)

On Windows, when display scaling is set to a value >100% (125% in my case) a single-line text-field% correctly renders one character, but as soon as a second character is typed, the top of all visible glyphs becomes clipped by a few pixels. The effect applies uniformly across the entire entered string: characters typed earlier also become clipped once a second character is added.

• Racket version: 9.0 and 9.1 (screenshots use 9.1)
• OS: Windows 11 Pro (24H2 / 63100.8037)
• Display scaling: 125%

Reproduction

1. Run the program below.
2. Click into the Default field.
3. Type a single uppercase character (e.g. P): renders correctly.
4. Type a second character (e.g. another P): tops of both characters are now clipped.

#lang racket/gui

(define frame
  (new frame% [label "text-field clipping repro"] [width 540] [height 380]))

(define container
  (new vertical-pane% [parent frame] [border 24] [spacing 14] [alignment '(left top)]))

(new message% [parent container] [label "Type 2+ characters into each field to compare:"])
(new text-field% [parent container] [label "Default:"])
(new text-field% [parent container] [label "min-height 28:"] [min-height 28])
(new text-field% [parent container] [label "min-height 32:"] [min-height 32])

(define padded
  (new text-field% [parent container] [label "editor padding 0 3 0 3:"]))
(send (send padded get-editor) set-padding 0 3 0 3)

(new text-field% [parent container] [label "14pt font:"] [font (make-object font% 14 'default)])

(send frame show #t)

After typing PPg into each field:

Workarounds attempted

• Increasing min-height (28, 32): does not fix the clipping.
• set-padding on the underlying editor: passing a top padding (2nd argument) shifts the text down so ascenders are no longer clipped, but the descenders are then clipped at the bottom instead. Changing the bottom padding (4th argument) from 0 to 3 had no observable effect.
• Larger font: reduces but does not eliminate the clipping.

Notes

• Changing Windows display settings from 125% to 100% scaling on all monitors and restarting DrRacket eliminates the clipping in all five fields, including the default. This points to a DPI scaling issue in the editor canvas's vertical metric or offset computation rather than a font/control issue per se.
• Clipping only appears once the line contains a second character. With exactly one character, rendering is correct in all fields. This may be a useful diagnostic; something in the redraw or layout path appears to be invoked or recalculated only when a line contains more than one snip.
• The fact that min-height does not eliminate the clipping suggests the cause is not simply that the canvas is too short — the text appears to be positioned with an incorrect vertical offset relative to the canvas, rather than the canvas lacking room for it.
• It seems set-padding's top parameter shifts the text, but the bottom parameter has no observable effect. May warrant separate investigation.

Start by running the provided racket/gui reproduction on Windows at 125% display scaling, then inspect the text-field% editor and editor canvas rendering or vertical-metric path. Compare one-character and two-character redraws, including the padding cases. Done means glyphs no longer clip in the listed fields at scaling above 100%, without introducing bottom clipping.