The window-focus signal had no business living on the notifications
primitive — it was there because the same NotificationsPlugin happened
to observe NSApplication active/resign for its own reasons. Splitting
it into a sibling XWindow primitive (with its own WindowPlugin on
macOS, ux/window/events) lets future consumers — paused video,
deferred-work scheduling, dock badge counts — read focus state without
pulling in UNUserNotificationCenter.
XNotifications now only exposes notification I/O (show/cancel + tap +
authorization). The 'type:focus' event-channel branch is gone.
Used during the desktop-tap-doesn't-highlight investigation; root cause
turned out to be in the app's router-traversal logic, not the plugin.
Strip the noise from the production logs.
Helps diagnose why .list-style entries aren't landing in Notification
Center on macOS — logs willPresent firing and the add() result so we can
distinguish 'delivery never happened' from 'system filtered the entry'.
Returning [.alert, .sound] from willPresent shows the banner but never
adds the entry to Notification Center — .alert has been a banner-only
shim since macOS 11. On 11+ we need [.banner, .list] for the entry to
stick after the banner auto-dismisses.
Generic OS-notification + window-focus surface. Hand-rolled MethodChannel
+ EventChannel, registered through XPlugin alongside the existing camera
/ video / clipboard plugins. macOS native handler uses
UNUserNotificationCenter with thread-grouping support, NSApp activation
on tap, and NSApplicationDidBecomeActive/DidResignActive for the focus
signal (more reliable than Flutter's AppLifecycleState on macOS).
