feat(peer): stamp launcher settings on first play, add PersonaName rewrite

Some games ship a SmartSteamEmu.ini somewhere under their installed
local/ tree with a `PersonaName = ...` line that must carry the player's
configured username. They also ship account_name.txt and language.txt
files that the launcher already overwrote with the username/language.

Previously that account_name.txt/language.txt overwrite happened inside
the install transaction, so it only applied to freshly (re)installed
games — games already installed by an older build never got fixed up,
and the SmartSteamEmu.ini PersonaName line was not handled at all.

This moves all per-user setting application out of install and into a
single one-shot step performed the first time a game is played, gated by
a new per-game marker `games/<id>/launch_settings_applied` under the
state dir. On first play we search the whole local/ tree and stamp:

  - the username into the first account_name.txt,
  - the language into the first language.txt,
  - the username into the first SmartSteamEmu.ini PersonaName line,
    preserving that line's existing line ending (\n or \r\n) and its
    surrounding whitespace, leaving sibling lines untouched.

The marker only records that we *tried*: it is written unconditionally
after the first play, so a game with none of these files is still marked
done and never rescanned. Because already-installed games have no marker
yet, they are fixed up on their next play rather than only on reinstall.

To keep the marker honest across version changes, the install and update
transactions now clear it on success, so a freshly extracted local/ is
re-stamped on the next play.

Behavior changes from the user's perspective:
  - The first time you press Play after this change, your username/
    language are (re)applied to an existing install, including games you
    installed before this feature existed.
  - SmartSteamEmu.ini's PersonaName now reflects the launcher username.

Plumbing: account_name/language are removed from PeerCommand::InstallGame
/DownloadGameFiles[WithOptions] and the whole install handler chain, and
the Tauri pending_install_settings bookkeeping is gone — the launcher now
computes the values at play time in run_game and calls
lanspread_peer::apply_launch_settings_once. The headless harness gains a
`play` command exposing the same step for scripted testing.

Test Plan
  - just test: new lanspread_peer::launch_settings unit tests cover the
    PersonaName rewrite, \n/\r\n preservation, first-match search, the
    unconditional marker, and the no-op-once-applied path; a transaction
    test covers the install marker reset. Whole workspace is green.
  - just clippy clean; the change adds no new clippy warnings (incl.
    --tests).
  - S38 (new in PEER_CLI_SCENARIOS.md): host run of lanspread-peer-cli
    against the new fixture-persona/css RAR .eti (with --unrar) installs
    css, then `play css` stamps the deeply-buried CRLF PersonaName line,
    account_name.txt, and language.txt and creates the marker; a second
    `play` is a no-op even after the values are reset externally.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

PEER_CLI_SCENARIOS.md

@@ -45,6 +45,7 @@ for deterministic local runs; mDNS/macvlan remains an environment smoke path.
 | S35 | Unknown game ID from remote peer | A remote peer advertises a game ID that is not in the receiver's catalog. | The receiver does not list the unknown game as downloadable, download attempts fail deterministically, and no local files are created. |
 | S36 | Latest singleton beats stale majority | Five peers advertise one game; one peer has `20260501`, four peers have `20250101`. | `list-games` reports `eti_game_version=20260501`; all descriptors and chunks come from the singleton latest peer; stale peers contribute zero bytes. |
 | S37 | Single-source download throughput | A source peer advertises a temporary catalog game with one sparse `2 GiB` `.eti`; an empty client downloads it with `install=false`. | The client emits `download-finished` with throughput measurements (`bytes`, `duration_ms`, `mib_per_s`, `mbit_per_s`), and the downloaded archive size matches the source. |
+| S38 | First-play launch-setting stamping | `fixture-persona/css` ships a real RAR `.eti` whose tree buries a CRLF `SmartSteamEmu.ini` with a stub `PersonaName` line under `engine/bin/win64/steam_settings/`, plus a stub `account_name.txt` and `language.txt` under `profiles/local/`. A peer installs `css` (with `--unrar`), then sends `play css` with a username and language, then `play css` again. | After install the marker `games/css/launch_settings_applied` is absent and the stub files are intact under `local/`. The first `play` returns `already_applied=false` with `account_name_written`, `language_written`, and `persona_name_written` all true; the deep `SmartSteamEmu.ini` `PersonaName` value becomes the username with its `\r\n` ending and sibling lines preserved, `account_name.txt` becomes the username, `language.txt` becomes the passed language, and the marker now exists. A second `play` returns `already_applied=true`, rewrites nothing, and leaves the files untouched even if their values were reset externally. |
 
 ## Version-Skew Contract
 
@@ -91,8 +92,44 @@ different `version.ini` contents. The existing alpha/bravo/charlie fixtures
 cover duplicate-source and shared-game cases, but not the three-version skew
 until a dedicated fixture or temporary games root is prepared.
 
+## First-Play Launch-Setting Contract
+
+Use S38 to pin down how launcher settings are stamped into an installed game:
+
+- Stamping happens on the first `play`, not during install/update. The install
+  transaction only clears the `games/<id>/launch_settings_applied` marker so the
+  next play reapplies settings to a freshly (re)created `local/`.
+- The first play stamps the username into the first `account_name.txt` and the
+  first `SmartSteamEmu.ini` `PersonaName` line, and the language into the first
+  `language.txt`, searching the whole `local/` tree. The matched `PersonaName`
+  line keeps its existing line ending (`\n` or `\r\n`).
+- The marker records only that we *tried*: it is written unconditionally after
+  the first play, so a game with none of these files is still marked done.
+- S38 needs a real archive expanded with `--unrar`, so it runs against the host
+  `lanspread-peer-cli` binary rather than the Docker matrix image (which omits
+  `unrar`). The peer crate's `launch_settings` unit tests cover the rewrite,
+  line-ending, and marker logic deterministically.
+
 ## Run Log
 
+### 2026-05-28 - First-Play Launch-Setting Stamping (S38)
+
+- Code under test moved the `account_name.txt`/`language.txt` overwrite out of
+  the install transaction and into a single first-play step (shared with the new
+  `SmartSteamEmu.ini` `PersonaName` rewrite) gated by the
+  `games/<id>/launch_settings_applied` marker.
+- `just test` passed the whole workspace, including the new
+  `lanspread_peer::launch_settings` unit tests and
+  `install::transaction::install_resets_launch_settings_marker`.
+- S38 host run: built `crates/lanspread-peer-cli/fixtures/fixture-persona/css`
+  with a stored RAR `.eti` (verified by `unrar t`) burying a CRLF
+  `SmartSteamEmu.ini` plus stub `account_name.txt`/`language.txt`. A host peer
+  installed `css` with `--unrar /usr/bin/unrar`, then `play css` stamped the
+  username into the deep `PersonaName` line (CRLF preserved, sibling lines
+  intact) and `account_name.txt`, the language into `language.txt`, and created
+  the marker. A second `play css` returned `already_applied=true` and rewrote
+  nothing even after the value was reset externally.
+
 ### 2026-05-19 - Snapshot Status Fix Docker Matrix Pass
 
 - Code under test included `5c4976d` (`fix(peer): settle local state before