fix(install): prefer the musl asset on NixOS and other non-FHS hosts

NixOS keeps glibc in the store, so a generic `-gnu` release binary cannot
find its dynamic loader. The old detection missed this twice over: `ldd
--version` reports plain GNU libc there, and `/lib64/ld-linux-x86-64.so.2`
does exist — as a stub that only prints an error and exits 127. The
installer downloaded the gnu asset, `executable()` returned 1, and the
binary could never start.

Detect non-FHS distributions (`/etc/NIXOS`, `ID=nixos`/`ID=guix` in
os-release) and pick the statically linked musl asset there. Turn the
single target triple into an ordered candidate list so glibc hosts fall
back to musl too, and verify the staged binary actually execs — exit 126
or 127 means the kernel or loader refused it — before it lands in `bin/`.

Applied to both installers (Lua and the Vim build hook, which the shell
test harnesses source). Adds `g:nuwiki_ls_target` to force a triple.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qPCSWXxATFvjEpVxQMhG9

doc/nuwiki.txt

@@ -62,6 +62,14 @@ Highlights:
 Install via your plugin manager; the build hook downloads a pre-built
 `nuwiki-ls` binary into the plugin's `bin/` directory.
 
+On Linux the installer picks the musl (statically linked) asset when the
+host is musl-based or is not an FHS distribution — NixOS and Guix System
+keep glibc in the store, so a generic `-gnu` binary cannot find its dynamic
+loader there. Elsewhere it prefers the `-gnu` asset and falls back to musl
+if the downloaded binary turns out not to run. Set `g:nuwiki_ls_target`
+                                                        *g:nuwiki_ls_target*
+to a release triple (e.g. `x86_64-unknown-linux-musl`) to force the choice.
+
 lazy.nvim: >
 
   {