Fix native child viewports aborting fullscreen on macOS

[smoe]

• Closes macOS: native child viewport flickers/aborts when opened from fullscreen or maximized root window #8259
• I have followed the instructions in the PR template

Problem

Opening a native child viewport (show_viewport_deferred / show_viewport_immediate) while the root window is in macOS native fullscreen makes AppKit renegotiate the active Space: the child flickers, can get pulled into Split View tiling — ending up unintentionally fullscreen itself — and the root's fullscreen state can be aborted. Reproduced with both the wgpu and glow backends; window state captured via AppKit before the fix:

window="Root window"     fullscreen=true   on_active_space=true
window="Child viewport"  fullscreen=true   on_active_space=true   <- pulled into Split View
+ one stale ghost window left behind

Fix

AppKit's mechanism for windows accompanying a fullscreen window (palettes, inspectors) is NSWindowCollectionBehaviorFullScreenAuxiliary. winit 0.30 doesn't expose it, and it must be set before the window is first ordered on screen — but winit shows windows during creation. So egui-winit now creates affected windows hidden, sets the collection behavior via objc2-app-kit, and then orders them front (respecting the builder's visible/active). Same pattern as the existing iOS safe_area.rs polyfill; I have proposed the API upstream (rust-windowing/winit#4614) so most of the new macos.rs module can be deleted when egui moves to winit 0.31.

New API: ViewportBuilder::with_fullscreen_auxiliary (macOS only):

• true: always mark the window as fullscreen-auxiliary,
• false: never,
• unset (default): auto — mark it if and only if the window is created while the app has a fullscreen window on the active Space, and the viewport doesn't itself request fullscreen. So child viewports "just work" from a fullscreen root, with no behavior change in any other situation.

Trade-off: an auxiliary window cannot itself enter native fullscreen. ViewportCommand::Fullscreen(true) / SetMonitor therefore clear the flag before toggling, so runtime fullscreen requests on child viewports keep working.

After the fix (same repro):

window="Root window"     fullscreen=true   on_active_space=true   <- stays fullscreen
window="Child viewport"  fullscreen=false  on_active_space=true   <- floats on the fullscreen Space

Testing

• Test app driving the full sequence (fullscreen root → open deferred child → inspect NSWindow state) on macOS 15 / Darwin 25.5.0, run against both wgpu and glow backends: root stays fullscreen, child shows on the same Space with the auxiliary bit set.
• Regression check with a windowed root: predicate is false, the child window is created visible by winit exactly as before (no auxiliary bit, no hidden-then-show).
• cargo test -p egui -p egui-winit, clippy (debug + release, all features), cargo doc -D warnings, lint.py, cargo fmt all pass.

Notes

• The issue also mentions a maximized root: a zoomed window involves no Space negotiation, and I could not reproduce any misbehavior there — I suspect those symptoms belong to the viewport transition issues addressed in Stabilize native viewport lifecycle and macOS wgpu fullscreen transitions #8280. This PR is orthogonal to (and compatible with) Stabilize native viewport lifecycle and macOS wgpu fullscreen transitions #8280; incidentally, the "extra ghost window" documented there also shows up in this issue's baseline repro, which supports that connection.

[github-actions]

Preview is being built...

Preview will be available at https://egui-pr-preview.github.io/pr/8286-macos-fullscreen-auxiliary-viewports

View snapshot changes at kitdiff

[yay]

Related: This PR handles native child-window creation on an existing fullscreen Space, while #8280 addresses viewport lifecycle and rendering failures during native fullscreen transitions.