Prefer video-native backends for Wallpaper Engine video projects and stop conflicting renderers

[louzt]

Issue Draft: Prefer video-native backends for Wallpaper Engine video projects and stop conflicting renderers

Summary

Some Wallpaper Engine video projects stay black on Wayland when routed through linux-wallpaperengine, even though the process stays alive. Waypaper should detect those projects from metadata and prefer a video-native backend such as mpvpaper or gslapper when available.

Repro

1. Use Waypaper with the linux-wallpaperengine backend on Wayland.
2. Select a Wallpaper Engine video project such as 1470208181.
3. Observe the output on the real desktop.

Actual behavior

• linux-wallpaperengine can stay alive while the desktop output remains black.
• Switching from a video wallpaper to a scene wallpaper can leave a previous dynamic renderer alive unless the transition is cleaned up explicitly.

Expected behavior

• Detect video projects from project.json.
• Resolve the actual entry file, not just the preview file.
• Prefer mpvpaper, falling back to gslapper when installed.
• Kill conflicting dynamic backends when switching between video, scene, and other animated backends.

Notes

• This is a behavior change, so it should be discussed in an issue before opening the PR.
• The metadata/type work from issue 01 should land first or be embedded carefully in this branch.

Validation

• Reproduce a real video -> scene transition on a multi-monitor Wayland setup.
• Confirm mpvpaper does not remain alive after switching to a scene wallpaper.
• Confirm linux-wallpaperengine is still used for scene and web wallpapers.

Proposed branch

• fix/wallpaperengine-video-handoff

[louzt]

Follow-up from local validation: web wallpapers are not all the same failure mode. EVA (web) is detected correctly and looks like a pointer/parallax-dependent case. Customizable Module Visualizer (web) exits immediately under linux-wallpaperengine on my setup and logs property/runtime issues, which suggests renderer compatibility limits rather than a Waypaper metadata miss. That feels worth treating as a separate compatibility-hardening track after the current backend-routing work.

[anufrievroman]

Like I mentioned in the PR comments, I actually don't think that it's Waypaper's job to fix bugs or WE backend. I am kind of against silently switching to other backends. It seems like a niche of a niche use case, for users who want to use WE, and play video, and happen to have other backends for that. Are these Steam videos so special that we really care so much to play them? I mean, the use case doesn't really justify the introduced complexity.

[louzt]

Closing in favor of the reduced #280 (cleanup + metadata module only,
no rerouting). The original proposal to route WE video projects
silently to mpvpaper / gslapper is out of scope per the
maintainer feedback on the issue and on #280 — Waypaper should not
make backend-selection decisions on the user's behalf.

The remaining slice of #280 (process cleanup + find_process_pids

• Wallpaper Engine metadata normalization) addresses a real, separate
  problem: conflicting dynamic renderers being left alive during
  backend switches on Wayland, and a tooltip that shows raw Steam
  Workshop numeric IDs instead of project titles. That work is being
  tracked on Route Wallpaper Engine video projects to video-native backends and clean up conflicting renderers #280 / Surface Wallpaper Engine project type in the UI #278 and is independent of this issue.

The CPU/battery tradeoff for raw .mp4 playback under
linux-wallpaperengine is real, but the right surface for it is an
informational advisory at selection time, not silent backend
switching. The advisory lands behind a config flag in #280
(cf.we_video_advisory, default ON, easy to opt out).