Address review findings in the app, server and tests

- app: startup shell, python and ssh probes run asynchronously so a slow
  shell profile can't freeze the window; PATH comes from the user's real
  login shell and a failed lookup isn't cached; a server that never
  answers is killed; the setup offer runs once per launch, only after the
  UI loads, and decides from HostName alone; connect.sh is started through
  `env ... zsh` so it works whatever the login shell is.
- server: volume validates the level before muting or changing anything.
- Steam: null-safe install-manager fields, http.client errors caught in
  store ratings, price fallback when a sale has no final price.
- tests: server output kept for diagnosis, any startup error retried, and
  captures asserted non-cacheable.

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

docs/vr-video.md

@@ -0,0 +1,81 @@
+# Watching VR video (180°/360°) on the Frame
+
+The confidence labels are the same as in [ssh.md](ssh.md). Everything here
+was checked on SteamOS 0.3.0, build 20260922.6101926.
+
+## The short version
+
+1. Install **DeoVR Video Player** from Steam (free, app 837380) and start it once
+   in the headset. That creates its Proton prefix.
+2. On the Mac: `scripts/push-vr-video.sh --launch ~/Movies/beach_180_LR.mp4`
+3. In the headset, open DeoVR's local file browser → **Videos → VR** and
+   pick the file.
+
+## Why DeoVR
+
+The Frame's Chromium can't play VR video in 3D. It has no immersive WebXR
+([how-the-frame-works.md](how-the-frame-works.md)). DeoVR's Windows build
+runs under Proton ARM64 + FEX as a real SteamVR app. **Verified 2026-09-25:**
+it found the Steam Frame headset and controller over OpenVR, and decoded
+7680×3840 and 8192×4096 H.265 VR180 side-by-side streams through AVPro's
+hardware Media Foundation path, mapped onto a 180° dome or fisheye mesh.
+
+Known quirks (verified):
+
+- The first launch takes about 45 s while it compiles shaders.
+- Grid thumbnails stay blank. Unity's own video player, which DeoVR uses for
+  previews, fails with `0xc00d36bb` under Proton. Full playback uses AVPro
+  and isn't affected.
+- The in-app store and web content are separate from local files. You don't
+  need an account to play your own files.
+
+## Getting files onto the headset
+
+`scripts/push-vr-video.sh` copies files with `rsync --partial`, so an
+interrupted upload resumes. They go to `~/Videos/VR` on the Frame (`/home`
+has about 860 GB free). The script also links that folder into DeoVR's prefix
+as `C:\users\steamuser\Videos\VR`. It's reachable at
+`Z:\home\steamos\Videos\VR` as well. **Verified** that the upload and link
+work. **Not yet checked** whether DeoVR's file browser lands there
+(open question 21).
+
+Speed: a test upload over Wi-Fi ran at about 3–5 MB/s (verified 2026-09-25,
+one sample). At that rate an 8K file of several GB takes tens of minutes, so
+start big uploads before you put the headset on.
+
+## Naming files so they play correctly
+
+DeoVR guesses the projection from the file name. Its binary contains the tags
+`_180`, `_360`, `_fisheye`, `_fisheye190`, `_mkx200`, `_vrca220` and `_rf52`
+(verified). For stereo layout, the common DeoVR convention is `_LR`/`_SBS`
+(side by side) and `_TB` (top/bottom) (inferred). If a video looks wrong
+(doubled, warped, or flat), change the projection and stereo mode in DeoVR's
+player menu.
+
+Examples: `trip_180_LR.mp4`, `concert_360_TB.mp4`, `hike_fisheye190_LR.mp4`.
+
+Codecs: H.265 at 8K played (verified, streamed). Local H.264 and H.265
+files haven't been played yet. The test clips below cover that.
+
+## Test clips
+
+The script doesn't include these. To check a setup, make two 20 s clips:
+3840×1920, 180° side by side, with the left eye tinted red and the right eye
+cyan. In the headset each eye should see only its own colour. A single mixed
+colour means the stereo split is wrong.
+
+```sh
+ffmpeg -f lavfi -i testsrc2=size=1920x1920:rate=30:duration=20 \
+  -filter_complex "[0:v]split[a][b];[a]colorchannelmixer=rr=1:gg=0.3:bb=0.3[l];[b]colorchannelmixer=rr=0.3:gg=1:bb=1[r];[l][r]hstack" \
+  -c:v libx264 -pix_fmt yuv420p -b:v 20M frame-test_180_LR_h264.mp4
+scripts/push-vr-video.sh frame-test_180_LR_h264.mp4
+```
+
+## Streaming from the Mac instead of copying (untested)
+
+DeoVR has a DLNA browser (the binary contains `Searching for DLNA
+devices...` and a UPnP ContentDirectory client). A DLNA server on the Mac
+should therefore appear in DeoVR without copying anything, for example
+`brew install rclone` then `rclone serve dlna ~/Movies/VR`. This is **inferred**, not
+tried. 8K VR video needs roughly 50–100 Mbit/s sustained, and the Wi-Fi
+sample above (about 30–40 Mbit/s) suggests copying first is the safer default.