fix(peer): refresh settled install state after operations

The follow-up review found a few stale lifecycle edges around local game
transactions. Recovery could sweep active roots, post-operation refreshes
still re-ran full startup recovery, and the UI kept inferring local-only state
from downloaded and installed flags instead of the backend availability.

This updates the peer lifecycle so startup recovery skips active operations,
install/update/uninstall refresh only the affected game after the operation
guard is dropped, and path-changing game-directory updates are rejected while
operations are active. It also removes the dead UpdateGame command, drops the
unused manifest_hash write field while preserving old JSON reads, renames the
internal install-finished event, and carries availability through the DB,
peer summaries, Tauri refreshes, and the React model.

The included follow-up documents record the review source, implementation
decisions, and the remaining FOLLOW_UP_2.md work so later commits can stay
small instead of reopening the completed plan items.

Test Plan:
- git diff --check
- just fmt
- just clippy
- just test

Follow-up-Plan: FOLLOW_UP_PLAN.md

crates/lanspread-peer/README.md

@@ -13,7 +13,7 @@ It is designed to run headless – other crates (most notably
   of the peer crate's platform layer, and the catalog set gates which local game
   roots are announced or served.
 - `PeerCommand` represents the small control surface exposed to the UI layer:
-  `ListGames`, `GetGame`, `DownloadGameFiles`, `InstallGame`, `UpdateGame`,
+  `ListGames`, `GetGame`, `DownloadGameFiles`, `InstallGame`,
   `UninstallGame`, and `SetGameDir`.
 - `PeerEvent` enumerates everything the peer runtime reports back to the UI:
   library snapshots, download/install/uninstall lifecycle updates, runtime