`MTKViewDelegate` declares two `@required` methods:
`mtkView:drawableSizeWillChange:` and `drawInMTKView:`. The
`QuadViewDlg` class only registered the latter, so any actual
drawable-size change (window resize, rotation under a non-locked
orientation set, split-view drag on iPad) crashed:

    *** Terminating app due to uncaught exception 'NSInvalidArgumentException',
    reason: '-[QuadViewDlg mtkView:drawableSizeWillChange:]:
    unrecognized selector sent to instance 0x...'
    ... [MTKView _resizeDrawable]
    ... [UIView setFrame:]
    ... [UIWindow _rotateWindowToOrientation:...]

Reproduced on the iPad Air 11-inch simulator on iOS 27 by rotating
the device. Did not reproduce on the iPhone 17 simulator there
because CHOMP's Info.plist locks orientation, so the drawable size
never actually changes.

Implementation is a stub: `draw_in_rect` already polls
`UIScreen.mainScreen.bounds` every frame and emits `Message::Resize`
on a delta, so a no-op satisfies the protocol without changing the
existing resize path.

Per Apple's MTKView contract, `drawableSizeWillChange:` is invoked
before the next `drawInMTKView:` whenever the drawable's pixel
dimensions change (window resize, rotation under a non-locked
orientation set, split-view drag on iPad). The previous commit added
a no-op stub to satisfy the protocol; that prevents the
"unrecognized selector" crash but leaves `native_display`'s stored
dimensions stale until the next frame's
`UIScreen.mainScreen.bounds` poll catches up.

During iPad rotation animations the stored dimensions stay one frame
behind the resized drawable. Anything that depends on the
framebuffer dimensions for the current pass — `setScissorRect` is
the common case — gets computed against the old size and fails
Metal validation:

    -[MTLDebugRenderCommandEncoder setScissorRect:]: failed assertion
    `Set Scissor Rect Validation
    (rect.y(688) + rect.height(2064))(2752) must be <=
    render pass height(2064)'

Update `native_display`'s `screen_width`/`screen_height` from the
size argument immediately and send `Message::Resize` so the event
handler resizes before the next draw. `draw_in_rect`'s own
`UIScreen.bounds` poll still runs as a fallback (e.g. for full-screen
size changes that don't go through the delegate).