fix(ios): size the new runtime's Metal drawable from the view's own bounds

[mfazekas]

New-runtime counterpart of #394, fixing #393 for the default backend. On devices where nativeScale != scale (Display Zoom, iPhone mini and Plus), MTKView derives its drawable size through ancestor transforms when it first attaches to a window, so a RiveView under a rotated parent renders squashed and one under a scale(0) parent stays blank.

rive-ios's RiveUIView creates its MTKView privately and asynchronously, so this observes the RiveUIView layer's sublayers to turn off autoResizeDrawable before the MTKView reaches the window, then sizes the drawable from the MTKView's bounds × nativeScale on layout and window changes. This also keeps touch mapping right, since RiveUIView maps touches with contentScaleFactor against drawableSize. The proper fix belongs in rive-ios; this can go once it lands there.

Verified on an iPhone 13 mini simulator (scale 3, nativeScale 2.88) with the new Issue393DisplayZoom reproducer page, reading drawableSize through lldb for 100×148 pt views:

1. Before: control 288×427, rotated 193×394, scale(0) inf×inf (blank). After: 288×426 for all three, contentScaleFactor 2.88, and no render errors.
2. Resize after mount and Remount keep the drawable in sync (130×103.7 pt → 374×299).
3. iPhone 17 (nativeScale == scale) is unchanged: 300×444, contentScaleFactor 3.
4. iOS harness on the mini: 29/29 suites, 209 tests pass.

No automated test: CI's iPhone 16 Pro has nativeScale == scale, so the bug can't trigger there.

[mfazekas]

Superseded by #401: rive-ios 6.28.0 fixes the drawable sizing upstream for both runtimes, so this workaround isn't needed. The Issue393DisplayZoom reproducer page moves to #401.