feat(peer): remove downloaded game files safely

Downloaded but uninstalled games can still occupy significant disk space. Add a
separate removal path for that state instead of overloading uninstall, which is
reserved for deleting only `local/` installs.

The peer runtime now exposes `RemoveDownloadedGame` with matching lifecycle
and active-operation events. The filesystem delete is intentionally strict: the
id must be a catalog game and a single path component, the target must be a
direct child of the configured game directory, the root must not be a symlink,
it must have a regular root-level `version.ini`, and it must not contain
`local/`, `.local.installing/`, or `.local.backup/`. Only then do we recursively
remove the game root.

The Tauri bridge exposes this as `remove_downloaded_game`, the frontend shows a
matching danger action only for downloaded-but-uninstalled games, and a
confirmation dialog warns that re-downloading can take a long time.

Test Plan:
- git diff --check
- just fmt
- RUSTC_WRAPPER= CARGO_BUILD_RUSTC_WRAPPER= just test
- RUSTC_WRAPPER= CARGO_BUILD_RUSTC_WRAPPER= just clippy
- RUSTC_WRAPPER= CARGO_BUILD_RUSTC_WRAPPER= just build

Refs: user redesign nitpick about removing downloaded uninstalled games

crates/lanspread-peer/README.md

@@ -84,12 +84,17 @@ When the UI asks to download a game:
 
 ### Install Transactions
 
-Install, update, uninstall, and startup recovery live under `src/install/`.
+Install, update, uninstall, downloaded-file removal, and startup recovery live
+under `src/install/`.
 Each game root has an atomic `.lanspread.json` intent log for install-side
 operations and uses Lanspread-owned `.local.installing/` and `.local.backup/`
 directories marked by `.lanspread_owned`. Startup recovery combines the recorded
 intent with the observed filesystem state and only deletes reserved directories
 when intent or marker ownership proves they belong to Lanspread.
+Downloaded-file removal is deliberately separate from uninstall: it only accepts
+catalog IDs that are direct children of the configured game directory, refuses
+installed or in-flight roots, and deletes the whole game root only after finding
+a regular root-level `version.ini` sentinel.
 
 ## Integration with `lanspread-tauri-deno-ts`
 
@@ -99,8 +104,9 @@ The Tauri application embeds this crate in
 - `LanSpreadState` holds onto the peer control channel, the latest aggregated
   `GameDB`, per-game operation state, the catalog set, and the user-selected
   game directory.
-- The Tauri commands (`request_games`, `install_game`, `update_game`, and
-  `update_game_directory`) translate UI actions into `PeerCommand`s. In
+- The Tauri commands (`request_games`, `install_game`, `update_game`,
+  `remove_downloaded_game`, and `update_game_directory`) translate UI actions
+  into `PeerCommand`s. In
   particular, `update_game_directory` validates the filesystem path before
   storing it, loads the bundled catalog on first use, kicks off the peer runtime
   on demand, and mirrors the installed/uninstalled state into the UI-facing