refactor(peer): make startup directory-driven

Peer startup used to bootstrap itself by spawning the runtime and immediately
sending a SetGameDir command back through its own control channel. The Tauri
integration then polled shared state until a directory appeared and waited two
seconds before asking peers for games. That made startup ordering implicit and
left a race-prone sleep in the UI bridge.

Install the initial game directory directly into the peer context instead. The
runtime now attempts the initial local-library scan before starting discovery,
then launches the server, discovery, liveness, and local monitor services from
that initialized context. Later directory changes still use SetGameDir, so the
existing UI command surface stays intact.

Use PathBuf and Path references across peer filesystem boundaries so directory
state is represented as a path rather than an optional string. The Tauri layer
now validates a selected game directory before storing it, loads the bundled
catalog on first use, and starts or updates the peer runtime from one helper.
Peer event fan-out is split into named handlers so the Tauri setup closure only
wires state and starts the event loop.

Shutdown goodbye notifications are still best-effort, but they are now awaited
with a short timeout instead of being spawned and forgotten. The tradeoff is a
small bounded wait during peer runtime shutdown in exchange for clearer task
ownership.

Test Plan:
- cargo test -p lanspread-peer
- cargo clippy
- cargo clippy --benches
- cargo clippy --tests
- cargo +nightly fmt
- git diff --check

Refs: none

crates/lanspread-peer/README.md

@@ -9,9 +9,10 @@ It is designed to run headless – other crates (most notably
 
 - `start_peer(game_dir, tx_events, peer_game_db)` boots the asynchronous runtime in the
   background and returns an `UnboundedSender<PeerCommand>` that the caller uses
-  for control. The function immediately forwards the supplied game directory via
-  `PeerCommand::SetGameDir` and keeps using the provided `PeerGameDB` so the UI
-  layer can observe live peer metadata.
+  for control. The initial game directory is installed directly into the peer
+  context, the local library scan is attempted before discovery starts, and the
+  provided `PeerGameDB` remains shared so the UI layer can observe live peer
+  metadata.
 - `PeerCommand` represents the small control surface exposed to the UI layer:
   `ListGames`, `GetGame`, `DownloadGameFiles`, and `SetGameDir`.
 - `PeerEvent` enumerates everything the peer runtime reports back to the UI:
@@ -20,7 +21,7 @@ It is designed to run headless – other crates (most notably
   `Game` definitions, tracks the latest ETI version per title, and keeps the
   last seen list of `GameFileDescription` entries for each peer.
 
-Internally the peer runtime owns three long-lived tasks that run for the
+Internally the peer runtime owns four long-lived tasks that run for the
 lifetime of the process:
 
 1. **Server component** (`run_server_component`) – listens for QUIC connections,
@@ -33,6 +34,8 @@ lifetime of the process:
    remains responsive.
 3. **Ping service** (`run_ping_service`) – periodically issues QUIC ping requests
    to keep peer liveness up to date and prunes stale entries from `PeerGameDB`.
+4. **Local game monitor** (`run_local_game_monitor`) – periodically rescans the
+   configured game directory and announces local library deltas to known peers.
 
 `scan_local_library` maintains a lightweight on-disk index and produces both a
 `GameDB` and protocol summaries. The resulting database is used to respond to
@@ -80,9 +83,10 @@ The Tauri application embeds this crate in
   `GameDB`, per-game download state, 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
-  particular, `update_game_directory` records the filesystem path, kicks off the
-  peer runtime on first use, and mirrors the installed/uninstalled state into
-  the UI-facing database.
+  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
+  database.
 - A background task consumes `PeerEvent`s and fans them out to the front-end via
   Tauri publish/subscribe events (`games-list-updated`, `game-download-*`,
   `peer-*`). Successful downloads trigger an `unrar` sidecar to unpack ETI