…giene

`Desktop app clean machine` is red nightly on main, seven AppImage jobs, all with
the app's own preflight naming four missing sonames. The tree is not at fault and
neither is the test, so this changes only what the verifier says.

What is actually happening
------------------------------------------------------------------------
The scheduled run downloads the published release rather than building one.
`REL_TAG` is `v0.1.800-beta`, whose Linux asset was uploaded 2026-08-14T15:26Z and
never rebuilt. I extracted it: `usr/bin/unsloth-studio` and zero `.so` files, so
it resolves webkit2gtk, libsoup, javascriptcoregtk and appindicator from the host.
It is a pre-#9113 thin build, provably: the diagnostic it prints lives at line 210
of `build-thin-appimage.sh`, a script #9113 deleted, and the replacement
`appimage-apprun.sh` does not contain that string.

#9113 ("Desktop: ship a complete Linux AppImage") landed 2026-08-19T13:09Z and
also dropped the line that used to install the host runtime into the appimage row,
which is correct under a self-contained bundle and is why that row flipped on an
unchanged asset. The Aug 18 run was green, Aug 19's red was the ManagedStale
incident that #9263 fixed, and Aug 20 is the first scheduled run after #9113.

So the asset under test predates the packaging it is being tested against. The
first desktop release cut from current main will satisfy these jobs; nothing in
the tree needs changing to make that true, and until that release exists this
workflow is red for a correct reason.

Note this is invisible on a pull request by construction: on `pull_request` the
AppImage jobs consume the artifact from `appimage-pr-build`, built from the PR, so
#9113 was green when it merged. Only `schedule` and `push` reach the release.

The one real defect
------------------------------------------------------------------------
`verify-complete-appimage.sh` run against that asset reports:

    Complete AppImage does not clear an inherited LD_LIBRARY_PATH

It exits 1 correctly, but it fails at the launcher-hygiene check and never reaches
the required-component loop, so a bundle that ships NO runtime at all is reported
as an environment-variable bug. That is the difference between an hour of
diagnosis and a minute of it.

The required-component check now runs first and reports every miss instead of
exiting on the first, mirroring the AppRun preflight, which names all four sonames
at once rather than making the reader rediscover them one launch at a time. On the
published asset it now says:

    Complete AppImage is missing required runtime component: libwebkit2gtk-4.1.so*
    ... 21 lines ...
    Complete AppImage is missing 21 of 21 required runtime components; it resolves
    them from the host

Order only. No check is removed and no assertion is weakened.

Verified
------------------------------------------------------------------------
`bash -n` clean. A synthetic AppDir with all 21 components present falls through
to the launcher-hygiene check exactly as before, so the hygiene checks still run
and still fail when they should. Removing only webkit from that AppDir yields
`missing 1 of 21`, so the count is real rather than a formatting flourish.
tests/security/test_release_desktop_appimage.py: 15 passed.