Syncing the Playnite plugin failed outright:
PUT /library/provider/playnite failed: entries[9]: launch.value for kind
launcher_ui names a launcher this host cannot open (playnite)
Two defects, and the second is why it cost every game rather than one tile.
1. The host looked for Playnite in the wrong registry hive and the wrong
profile. `playnite_fullscreen_exe()` read HKEY_CURRENT_USER, then fell back
to %LOCALAPPDATA% — but the Windows host is a LocalSystem service, so its
HKCU is the SYSTEM hive (S-1-5-18) and its %LOCALAPPDATA% is
C:\Windows\System32\config\systemprofile\AppData\Local. Playnite installs
per-user by default, so both lookups miss on a default install. The doc
comment reasoned correctly that Playnite is per-user and then read the one
HKCU that cannot see it.
It also hardcoded `…\Uninstall\Playnite`. Playnite ships an Inno Setup
installer, and Inno registers `<AppId>_is1` — measured on a Windows box
where Git and Inno itself appear as `Git_is1` and `Inno Setup 6_is1` — so
that key matched nothing anywhere.
Now: every loaded hive under HKEY_USERS plus both HKLM views, matched on
DisplayName rather than key name, then `C:\Users\*\AppData\Local\Playnite`
for the conventional install (and for a user whose hive is not loaded).
2. One unopenable tile 400'd the whole reconcile. The Playnite plugin appends
a single launcher tile beside its games, so refusing the payload cost the
operator the entire library — the same shape as the unservable-cover bug
that sanitize_art_paths was introduced to fix, on the launch side this time.
`valid_launcher_ui` conflated two different failures. Split into
`known_launcher_ui` (vocabulary — a plugin bug, still a hard 400, because
the author has no other way to find out) and `resolvable_launcher_ui`
(environment — the launcher just is not installed here, which is a fact
about the box). `sanitize_launcher_entries` drops only the latter, with one
warn, and the games sync.