Fix AppKit live resize redraw timing

[yay]

This fixes macOS live-resize behavior for layer-backed winit views.

While investigating resize artifacts in a downstream app and looking at other AppKit/Metal applications with smooth live resize behavior such as Zed editor, I found that AppKit can update and ask a layer-backed content view to display during live resize through paths that winit was not fully using for surface resize/redraw timing.

The main issue is that during live resize, the view backing size and redraw timing need to stay synchronized with AppKit's resize/display callbacks. Otherwise surface users can render with stale size information or miss redraw opportunities during the event-tracking run loop. In practice this shows up as visible wobble/jitter and stale or stretched frames while the window edge or corner is being dragged.

This PR changes the AppKit view path to:

• set NSViewLayerContentsRedrawDuringViewResize for the content view
• handle setFrameSize: by updating the surface size and requesting redraw during live resize
• handle viewDidChangeBackingProperties for backing-scale/backing-size changes
• handle displayLayer: as a redraw signal during live resize
• report surface size from convertRectToBacking(bounds) instead of deriving it from the window/frame size

Validation

I used a small winit + CAMetalLayer demo that:

• renders an animated high-contrast grid
• paints only from WindowEvent::RedrawRequested
• does not use an external AppKit timer
• does not enable CAMetalLayer.presentsWithTransaction

I recorded the same demo before and after the fix:

Before:

before-the-fix.mp4

After:

after-the-fix.mp4

In the before video, live resize shows stale/stretched frames. In the after video, resizing stays synchronized and smooth.

I also validated the same change against winit 0.30.13, since that is the version used by the downstream app where I first reproduced the issue.

---

Downstream validation/follow-up in egui: emilk/egui#8229.

That PR uses this winit change as the windowing-layer part of the fix, then handles the renderer-specific egui-wgpu/Metal presentation policy separately.

[yay]

@madsmtm Gentle bump - does this approach look acceptable?

[kchibisov]

@tronical @ogoffart would you mind taking a look? I don't have macOS machine around to check macOS stuff myself, but this might be interesting to you?

[tronical]

Looks overall good to me. A few questions inside, and I think that unsafe call can be replaced with a clean safe call :)

[yay]

Thanks for reviewing! Just addressed all comments. Sorry it took me a while to get back to it, even though I was the one who bumped it.

[tronical]

This only touches appkit files and that part is green in the CI. the linux failures are unrelated and already fixed on master. So merging this one :)