enricobuehler
85473e15dc
`defineLibraryPlugin` has taken a `launchers()` hook since kit 0.3.0 — entries that open the LAUNCHER rather than a title (design D4) — and nothing implemented it. The host has resolved `launcher_ui` valued `"heroic"` since the same release. So the whole path existed end to end with no producer at either end. One entry, config-toggled and on by default: installing, updating or logging in are exactly the things you cannot do from a game tile. `launcher_ui` is valued by STORE ID, never a command: the host resolves "heroic" to the native binary or the Flatpak, minus the `--no-gui` and the URI that game entries carry, so the window itself opens (D1). That is also the only shape available to a plugin at all — the 2026-08-05 review made `launch.kind = "command"` operator-only, so a plugin publishing one has its entire reconcile refused. CAVEAT carried in the code: Heroic is a single-instance Electron app, so if a window is ALREADY open the spawned process forwards to it and exits. The host documents the same caveat for game launches; keeping the session alive across it is a host-side question (the launcher-tile lease), not this plugin's. Deliberately art-less — see the lutris plugin: a square app icon cover-cropped into a 2:3 tile looks broken, and every client renders an art-less launcher entry as "opens Heroic" on purpose. Gates: tsc --noEmit clean, 7 tests pass (2 new), biome clean. Needs a host carrying the M2 wire (`role` + `launcher_ui`), which is on main.