SteamOS NVIDIA Installer 0.1.6

This release stops two fixes from switching themselves off, ends a hang that made
the machine look dead after leaving a streamed game, and lets the installer use a
disk that already holds a system.

• The Gamescope capture correction now follows the package it was built from,
  not a SteamOS release number. Valve moved stable from 3.8.16 to 3.8.28 on
  22 September with Gamescope 3.16.23.6-1. The previous rule required SteamOS
  3.8.16 and Gamescope 3.16.23.4-1 exactly, so an ordinary system update switched
  the correction off. Nothing failed and nothing was logged as an error: the
  status file simply read stock, and outgoing Remote Play showed a black
  picture at the other end. The artifact is now selected when the installed
  Gamescope package matches the one it was compiled against, on the SteamOS 3.8
  line, and stands aside otherwise. Measured on hardware across a move to 3.9.2
  Preview and back: the correction is chosen on 3.8.28, stands aside for Valve's
  newer Gamescope on 3.9.2, and returns on its own afterwards.

• The Remote Play receiver no longer wedges when a stream ends. Leaving a game
  that was being streamed to this machine could leave Steam's streaming_client
  alive but unable to exit, with the compositor still showing its last, black
  frame. The machine looked hung while it was in fact working, ignored SIGTERM and
  needed SIGKILL. The receiver driver waited for a decoded surface with no
  timeout, while every path that ends the thread able to release it left surfaces
  marked as in progress. It now releases what it abandons, and bounds the wait,
  naming the surface in the log if it gives up. The pinned upstream revision
  carries no fix for this and no upstream issue covers it, so the patch is this
  project's own. Installer Update cannot deliver this one, because the
  receiver driver is compiled rather than scripted: an affected system needs a
  new image.

• The installer offers a disk that already holds an installed system, and
  unmounts it first. Any machine with a system on it reported no available
  target, because the installer environment mounts an installed system's
  partitions automatically and the picker treated a mounted disk as unavailable.
  The workaround was to delete the partitions by hand, after which the installer
  erased the disk anyway. The list now names what each disk holds, an existing
  SteamOS installation, a count of other partitions, or none, and releases the
  chosen disk before writing. It refuses with the partition and mount point named
  if that fails, and refuses to touch a disk in use as swap.

• The updater records which SteamOS releases were tested instead of refusing
  every other one. Releases declared a single version and the updater refused
  anything else, so this release would have been refused on current stable, and
  the next point release would do it again. Below the oldest tested release the
  update still refuses and names it, because there is nothing to stand on. At or
  above it the update proceeds and says on standard error what was tested and what
  this system reports. A release that genuinely does not fit still fails loudly:
  the integration ends by verifying every addon and aborts the transaction rather
  than degrading quietly. This release declares 3.8.14, 3.8.16, 3.8.28 and 3.9.2.

Build tooling, which does not change an installed system:

• The complete builder no longer demands one recovery release. Valve publishes a
  single current image and replaces it over time, so the builder records the
  release it finds and warns when it is not one this project has validated. What
  it still refuses is a build root whose package repositories come from another
  SteamOS line. Validated releases and the tested driver now live in one file,
  config/build-baselines.json, read by the builder, the artifact guard and the
  installer.
• The plain installer defaults to the tested driver instead of whatever Arch
  ships that day. --driver latest remains available and is now a deliberate
  choice.
• Artifact metadata is recorded in a fixed order, so the same commit built on
  different hosts produces the same files. Four hosts now agree on the same 89
  addon files.
• The two artifact builders that compile against libdrm declare the kernel
  headers they need. They previously worked only because the complete build runs
  them after two builders that installed the package, so building one artifact on
  its own, which --remote-play-dir and --nvenc-dir are documented to accept,
  failed at the first object.
• An image records the commit it was built from again. The build runs as root
  against a checkout owned by the build user, git refused the repository, the
  message went nowhere and the recorded value became unknown.

Validation. Every change that reaches an installed system was accepted on
hardware: an RTX 5060 with NVIDIA 610.57.04. The candidate image was installed
over an existing system without deleting partitions by hand, the first SteamOS
update was applied and moved the machine to 3.8.28, and every addon, the driver
rebuilt for the new kernel, the userspace check and the read-only root were
verified afterwards. The receiver fix was exercised three times, leaving a game
inside a live session and disconnecting the session completely, and then again
from the image. The machine was moved to 3.9.2 Preview and back: the driver
rebuilt for a kernel from a different series, the addon digest was identical at
all three stops, and the Gamescope selection behaved as described above. The
candidate's payload was compared against the image already accepted on hardware:
89 files, nothing added or removed, 87 byte-identical, and the two that differ
are this release's own changes. The source tree passes its suite on Linux, 242
tests with one skip, including the five files that cannot run on Windows.

Known and not fixed here: a picture streamed from a PC to this machine arrives at
about 64 percent of the brightness it left with. That was measured on two
different SteamOS releases, with two kernels and two compositors, with hardware
decoding on and off and hardware encoding on and off, and in the opposite
direction the same pair of machines is correct. Nothing this project installs is
in that path. See the Troubleshooting page.