Is your feature request related to a problem? Please describe.
It is currently impossible to detect whether or not the desktop is focused in an HTML wallpaper, without having the entire wallpaper paused.
I've been attempting to implement my own audio fading in/out logic in a custom wallpaper, as the built-in feature to mute audio when another application is in focus is quite abrupt at times. Though, I haven't found any way to properly detect when the wallpaper gains/loses focus. The closest I've gotten has been using the livelyWallpaperPlaybackChanged feature and detecting when lively pauses/unpauses my wallpaper. However this has the unintended consequence of also pausing video playback, and also abruptly muting the audio shortly after pausing, before the custom wallpaper has finished fading out the audio completely.

Describe the solution you'd like
A similar feature to the pause event (livelyWallpaperPlaybackChanged callback), but instead of firing whenever the wallpaper is paused/resumed, it fires whenever the active application has changed from the desktop to another app, or vice versa - without any actual pausing of the wallpaper.
This could be called a "focus event", with a livelyWallpaperFocusChanged function callback. This would receive an object containing a IsDesktopFocused bool value.
Using this instead of the pause event would allow the wallpaper to implements its own custom pausing/muting behavior without relying on lively's.

Describe alternatives you've considered
My first attempt at this involved using onfocus and onblur JS window events, which worked perfectly in a browser, but as a lively wallpaper it only ever called focus the first time you clicked on the desktop, never losing focus. If this is unintended behavior and is possible to fix, this would be a good alternative.

Additional context
While the initial use case that inspired this suggestion could be its own feature request (fading wallpaper audio in and out), I'd still advocate for a general-purpose focus event, as it would let us implement our own custom solutions to some feature requests (e.g. #1249), and enable for a lot more customizability.