Since alpha.93, the default Linux build target is GTK4 / WebKitGTK 6.0
(GTK3 / WebKit2GTK 4.1 is now the legacy `-tags gtk3` path). The AppImage
bundler still hard-coded the GTK3 set of runtime files, so on a runner
with only the GTK4 toolchain installed `wails3 generate appimage` aborted
with:

    ERROR  Unable to locate all required files: libwebkit2gtkinjectedbundle.so

Move the ldd-based version detection in front of `findGTKFiles`, run it
on the source binary (not the post-copy path, which `filepath.Join` mis-
handles when `-binary` includes a path), and pick the injected-bundle
filename to match: `libwebkitgtkinjectedbundle.so` for GTK4, the older
`libwebkit2gtkinjectedbundle.so` for GTK3. `WebKitWebProcess` and
`WebKitNetworkProcess` are unchanged - both stacks ship them.

Also extend `hasRelrDynSections` to probe `libgtk-4.so.1` (plus aarch64
paths) so the strip workaround introduced in #4772 still triggers on
modern toolchains regardless of which stack the user built against.

Verified on Ubuntu 26.04 lin-node1:

- Default (GTK4): `go build` then `wails3 generate appimage` bundles
  `libwebkitgtkinjectedbundle.so` under `webkitgtk-6.0/injected-bundle/`
  in the AppDir; the resulting AppImage launches under xvfb and logs
  `GTK=4.22.2 WebKitGTK=2.52.3`.
- Legacy (`-tags gtk3`): same flow bundles
  `libwebkit2gtkinjectedbundle.so` under `webkit2gtk-4.1/injected-bundle/`
  and the AppImage launches with `Webkit2Gtk=v2.52.3` and `-tags=gtk3`.

Two pre-existing unrelated issues observed during verification, flagged
here so reviewers don't conflate them with this fix:

- `wails3 generate appimage` with a relative `-builddir` races on the
  AppRun download goroutine because `s.CD(BuildDir)` is called between
  the goroutine launch and its file write. Workaround: pass absolute
  paths.
- The post-bundle `s.MOVE` expects the AppImage to be named after
  `normaliseName(filepath.Base(Binary))`, but `linuxdeploy` names it
  after the desktop `Name=` field, so the move fails when those don't
  match. Workaround: align `Name=` with the binary basename. Will be
  addressed in a follow-up.

Refs #5475.

Two pre-existing bugs surfaced while verifying #5475:

1. `wails3 generate appimage` with a relative `-builddir` would fail
   inside the AppRun download goroutine. The flow does `s.CD(BuildDir)`
   between launching the goroutines and their file writes, so any
   path computed before the CD (e.g. `appDir = filepath.Join(BuildDir,
   "...AppDir")`) was being resolved relative to the wrong CWD by the
   downstream `s.DOWNLOAD(target)` and the `ldd <binary>` shell-out.

   Fix: resolve `-binary`, `-icon`, `-desktopfile`, `-builddir` and
   `-outputdir` to absolute paths up-front, alongside the existing
   `OutputDir` resolution. Now CWD-sensitive operations downstream
   all see stable absolute paths.

2. The post-bundle `s.MOVE(targetFile, OutputDir)` would fail when the
   desktop file's `Name=` field didn't match `normaliseName(basename(
   Binary))`. linuxdeploy's appimage plugin names the output AppImage
   from the desktop `Name=`, but the Go code expected
   `<binary>-<arch>.AppImage` and looked it up by that path.

   Fix: set the `OUTPUT` env var (honored by linuxdeploy-plugin-appimage)
   to the binary-derived name we already expect, so the produced
   filename matches what we then move.

Verified on Ubuntu 26.04 lin-node1:

- Relative `-builddir` + a desktop `Name=Differently Named App` (which
  used to fail twice over): exit 0, AppImage produced at
  `out/appimage-smoke-gtk4-x86_64.AppImage`, launches under xvfb,
  logs `GTK=4.22.2 WebKitGTK=2.52.3`.
- The original absolute-paths flow (both GTK4 default and `-tags gtk3`)
  still produces the matching AppImage in `-outputdir` and exits 0 -
  no regression of the #5475 fix.

Refs #5475.

…ailure

Addresses CodeRabbit and Copilot review on #5476:

- Quote the binary path passed to `ldd` (`%s` -> `%q`). `s.EXEC` splits
  the command string with shlex; an unquoted path with spaces gets
  fragmented and the ldd call fails.
- Same treatment for the `readelf` probe in `hasRelrDynSections` and
  for the `linuxdeploy ... --appdir <dir>` command. The linuxdeploy
  call site was the latent breakage — invoking it with a `-builddir`
  containing a space produced `fork/exec /tmp/space: no such file or
  directory` even after the abs-path resolution from the previous
  commit.
- Include a truncated ldd-output snippet in the
  "unable to determine GTK version" error so users hitting this branch
  can see which libraries the binary actually links against.

Verified on lin-node1 (Ubuntu 26.04):

- Paths with spaces (`-binary "/tmp/space test/my app"` ...): now exit
  0 and produce `out/my-app-x86_64.AppImage`. Previously failed at
  the linuxdeploy step.
- The original absolute-path GTK4 and `-tags gtk3` flows still pass
  and the GTK4 AppImage still launches under xvfb with
  `GTK=4.22.2 WebKitGTK=2.52.3` - no regression.

Refs #5475.