Docs: record round-2 Frame verification and remaining gaps

Frame Control 0.4.10

app/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "frame-control",
-  "version": "0.4.9",
+  "version": "0.4.10",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "frame-control",
-      "version": "0.4.9",
+      "version": "0.4.10",
       "license": "MIT",
       "devDependencies": {
         "electron": "^44.4.5",

app/package.json

@@ -1,7 +1,7 @@
 {
   "name": "frame-control",
   "productName": "Frame Control",
-  "version": "0.4.9",
+  "version": "0.4.10",
   "description": "Desktop app for managing a Valve Steam Frame over SSH",
   "private": true,
   "main": "main.js",

docs/backup-and-recovery.md

@@ -14,6 +14,13 @@ reported Game Mode, so **Return to Game Mode** changed nothing. Not tested on a
 headset: a restore after a real factory reset, a restore that replaces files,
 Android data restore, and the switch out of a real Desktop Mode session. Unit
 tests and the fake Frame cover those (see [Verification](#verification)).
+On 2026-10-24 a read-only session check on the same build again reported Game
+Mode (`gamescope=true`, `plasma=false`, `nested_desktop=false`) and the
+`steamos-session-select` command was present. Opening the nested desktop for a
+clipboard test did not enter full Desktop Mode. A full session switch was not
+attempted because it restarts the headset session and a reliable return path
+was not established; the **Return to Game Mode** branch for a real full
+Desktop Mode session remains unverified.
 
 ## Back up
 

docs/file-transfer.md

@@ -62,6 +62,12 @@ refused with a message, so send big things as a file. An empty clipboard, or
 one holding an image, says so. Neither the server nor its log ever records what
 was on the clipboard.
 
-**Not tested on a headset yet.** Reading uses the same Klipper interface as
-sending, which was verified on 2026-09-25, but `getClipboardContents` itself
-hasn't been tried on a Frame. The fake Frame (`tests/fakeframe`) answers it.
+**Verified on a Frame, 2026-10-24:** SteamOS 0.5.6, build
+`20261015.6141207`. With a temporary nested desktop open, Frame Control sent
+a 47-character test marker to Klipper, then **Copy the headset's clipboard**
+read it through `getClipboardContents` and set a Linux PC's X11 clipboard.
+Reading that PC clipboard returned the exact marker. The prior headset
+clipboard was restored and the test desktop was closed. The PC side used a
+temporary X display on lxso2; macOS and Windows clipboard backends, a user's
+copy action in a headset app, and image/size error cases remain untested on a
+real headset. The fake Frame (`tests/fakeframe`) covers the protocol cases.

docs/recording.md

@@ -149,11 +149,12 @@ recording with Steam's file names and export it with the real `ffmpeg`.
 
 ## What hasn't been checked
 
-None of this has run on a Steam Frame yet. In particular:
+The 2026-10-24 read-only clip list on build `20261015.6141207` again returned
+zero clips: its `gamerecordings` directory held only `gamerecording.pb`. No
+Steam recording was created during that check, so a real Steam clip export is
+still unverified. The recording and Stop path were verified earlier on that
+build, as described above. Remaining checks:
 
-- That SteamOS's `ffmpeg` can read `@DEFAULT_MONITOR@`. It has the PulseAudio
-  output device (the media player plays through it), so the input is expected,
-  but if it fails the recording is video only, as above.
 - Audio and video sync. Both inputs are stamped with the wall clock, because
   the camera device and the audio server otherwise count from different clocks.
 - The exact layout of `gamerecordings` on the Frame's SteamOS build, and