FrameMover v1.2.0: A little bit less janky

Fixes

• Moves are no longer dropped, or left on a stale playspace, when the headset switches tracking universe. On the Frame a universe switch (relocalizing against a saved map, a new tracking world, standby) is announced only by VREvent_ChaperoneFlushCache, and SteamVR silently throws away the live preview when it happens: zero pose and huge play area both. The mover now reads the universe id several times a second. A relocalization keeps your move and puts it on top of the new saved playspace; losing tracking and starting a new tracking world drops it (raw tracking space is not the same any more).
• Height moves no longer snap back to the floor after a fresh boot. The Frame relocalizes into your saved playspace, and while that playspace is still stored against an older tracking map, SteamVR writes its floor height into the live origin many times a second (x, z and turning were unaffected). This is why using the playspace editor once after boot made the tool work: its Accept re-stores the playspace against the current map. The mover now does that itself the first time it sees the height pinned: it backs up chaperone_info.vrchap, commits your saved playspace unchanged (same walls, same origin in the room) and puts your move back. Moves themselves are still never committed.
• Huge chaperone survives a universe switch: the mover checks the play area SteamVR reports, not only the zero pose, and writes it again when it was dropped.
• No more reading its own preview back as the saved playspace. Hiding the preview is asynchronous; the capture that follows a reset now waits until SteamVR serves the saved playspace again (about 10 ms while tracking, a second or more in standby), so the "original" is really the original.
• "Huge chaperone" off and Reset put your walls back again. The saved wall bounds were never captured (SteamVR returns false for the count-only query even though it fills in the count), so turning the option off or resetting left the walls SteamVR had at that moment.
• Pausing no longer lasts for good. After another program edited the working copy the mover resumes after 3 s; after SteamVR's room setup starts it resumes when setup reports back, or after 90 s if it was cancelled.
• Bindings no longer reset to the defaults after restarting SteamVR. SteamVR loads bindings saved from its editor from the Steam Workshop; when the controllers connected before Steam had logged in, that load failed and it silently used the shipped defaults (vrserver: "Tried to load url that was not a file path while steam is not available ... Silently falling back to the default binding"). The mover now keeps a local copy of your saved bindings in ~/.config/frame-mover/user-bindings/ and points SteamVR at it, at every start and after every reload of the bindings.
• --selftest refuses to run while the headset is in standby. There SteamVR has no saved playspace to restore, and the test move could be stored as the origin of the next playspace SteamVR creates. Stop the running mover first; it owns the dashboard tab.

New

• Small event log in ~/.local/share/frame-mover/frame-mover.log: one line for each tracking universe switch, rebase of a move, playspace replaced by SteamVR, re-anchor, binding pin and error. Capped at 64 KB plus one older copy, so it never takes more than about 128 KB.

Upgrading

Run the new FrameMover-installer-aarch64.AppImage and pick Install, or ./build/frame-mover --install. Restart FrameMover (or SteamVR) to load the new version.