fix(peer): repair update lifecycle regressions

FINDINGS.md identified three merge blockers in the post-plan install/update
flow.

Updates now use FetchLatestFromPeers so the Tauri update command bypasses
local manifest serving and asks peers that advertise the latest version for
fresh file metadata. PeerGameDB now aggregates and validates file descriptions
from latest-version peers, keeping stale cached metadata for older versions
from poisoning chunk planning when filenames stay the same but sizes change.

Download-to-install handoff now performs explicit async state transitions.
The download task mutates Downloading to Installing or Updating under the
active-operation write lock, clears the cancellation token, and then runs the
install transaction. OperationGuard remains armed only as crash or abort
cleanup and is disarmed after normal explicit cleanup, so final refreshes no
longer race a deferred Drop cleanup.

Local library index writers now serialize the load/mutate/save window with one
async mutex. The index fingerprint also includes the root version.ini contents
so a same-length version rewrite in the same mtime second still updates the
reported local version.

The tradeoff is that local index mutations are serialized in-process instead
of moved into a dedicated actor. That keeps the fix small and scoped to the
merge blockers while preserving the existing scanner API.

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

Refs:
- FINDINGS.md

crates/lanspread-peer/README.md

@@ -13,8 +13,8 @@ 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`,
-  `UninstallGame`, and `SetGameDir`.
+  `ListGames`, `GetGame`, `FetchLatestFromPeers`, `DownloadGameFiles`,
+  `InstallGame`, `UninstallGame`, `SetGameDir`, and `GetPeerCount`.
 - `PeerEvent` enumerates everything the peer runtime reports back to the UI:
   library snapshots, download/install/uninstall lifecycle updates, runtime
   failures, and peer membership changes.
@@ -57,9 +57,10 @@ lifetime of the process:
 
 When the UI asks to download a game:
 
-1. The UI first issues `PeerCommand::GetGame`. Each peer that still reports the
-   game is queried via `request_game_details_from_peer`, and their file
-   manifests are merged inside `PeerGameDB`.
+1. The UI first issues `PeerCommand::GetGame` for a new download, or
+   `PeerCommand::FetchLatestFromPeers` for an update that must bypass local
+   archives. The selected peers are queried via `request_game_details_from_peer`,
+   and their file manifests are merged inside `PeerGameDB`.
 2. Once the UI receives `PeerEvent::GotGameFiles`, it forwards the selected file
    list back with `PeerCommand::DownloadGameFiles`.
 3. `download_game_files` starts a version-sentinel transaction, parks any old