fix: bind AppImage updates to the running bundle

docs/launcher-architecture.md

@@ -220,7 +220,11 @@ The webview supplies no URLs, public keys, executable arguments, release version
 or arbitrary file path. No generic updater plugin permission is granted to it.
 The packaged native architecture selects the artifact: Windows preserves MSI
 versus NSIS, macOS preserves Intel versus Apple Silicon, Linux only replaces an
-AppImage. A Debian installation requires the user's package manager.
+AppImage. The original non-symlink AppImage must have the expected native header,
+and the frozen Tauri `APPDIR` must contain the actual running executable at
+`usr/bin/shacraft-launcher`. Extracted binaries and inherited context from another
+AppImage require manual installation. A Debian installation requires the user's
+package manager.
 
 Checks run once per application UI lifecycle and on explicit request. They do
 not install automatically. The settings drawer shows installed/available

docs/updater-release.md

@@ -184,7 +184,10 @@ updates preserve it:
   into an appropriate Applications directory before use. A protected destination
   may require OS permission or a manual replacement; an installation error never
   counts as a completed update.
-- Linux x64 AppImage → x64 AppImage at its current writable location. Debian
+- Linux x64 AppImage → x64 AppImage at its current writable location. The original
+  ordinary, non-symlink AppImage must exist, and the frozen Tauri `APPDIR` must
+  match the running `usr/bin/shacraft-launcher`. Extracted AppDirs and an inherited
+  environment from another AppImage use manual installation. Debian
   packages, RPM, bare development binaries and unsupported architectures never
   enter the self-replacement path. Install a new deb through the system package
   manager; the launcher does not run privileged package-manager commands.