With every feature merged in the overnight stretch, packaging was the last step before the owner could retest version one as a normal application. The owner had asked for exactly that: a build to install and use.
What it does
A per-user setup, so no administrator prompt. It registers the app under Open with and in Default apps for PDFs, and keeps one window: a second launch hands its file to the running instance, where it replaces the open document rather than opening a tab. One command builds the setup and prints its hash.
Two decisions
The owner’s current PDF reader must stay the default. So the registration is written by the installer’s own hooks rather than the framework’s file-association feature, which would have claimed the default. The app appears in the chooser and the owner picks. Uninstall removes only the keys it wrote. And there is no code signing: Windows will warn once on first run, and a certificate is a cost that a personal tool does not justify.
The sandbox
Both “real” install tests, the builder’s and the manager’s, turned out to have run inside the package sandbox of the desktop app that hosts the sessions. The install directory and every registry write were silently redirected into that package’s private store, so Explorer never saw the association. The installer’s logic is proven; whether it registers in a real profile is now the first item on the owner’s retest list.