An archive DLoad cannot unpack is selected instead of an older release's binary #152

Description

When a <binary> is configured and the type is not phar, DLoad still selects an asset in an archive format it cannot open: .tar.xz, .tar.bz2, .7z, .zst, .pkg.tar.zst (Arch). If that is the only asset for the host, it is downloaded, NullArchive yields the file itself, and the installation fails with NothingExtracted. That happens after the downloader has returned, so older releases that ship a supported archive are never tried and the whole get fails.

Expected: an asset DLoad cannot unpack is not selected when a binary is expected, and the downloader moves on to an older release — the same way #149 handles OS packages (.deb, .rpm, .msi…).

Steps to reproduce

1. Configure software with a <binary> and an asset-pattern matching a release whose only Linux asset is tool-linux-x86_64.tar.xz, while an older release ships tool-linux-x86_64.tar.gz.
2. Run dload get on Linux.
3. The .tar.xz is downloaded and the installation fails with NothingExtracted; the older .tar.gz release is not tried.

Proposed solution

• Cheap step: in strict mode, remove the extensions AssetName::EXTENSION knows but ArchiveFactory cannot open (it supports zip, gz, tar.gz, phar), next to PackageRule from fix(downloader): skip OS packages when a binary is expected #149. .AppImage stays: it runs as is.
• General fix: treat NothingExtracted as a failure of the asset by moving the installation into the release loop, which would also cover an archive that does not contain the binary.

Additional context

Found while reviewing #149.