[Bug] Linux AppImage caches /tmp/.mount_XXXX server path in Electron Local Storage → "Executable not found" on every launch after the first

Environment

• FreeMoCap version: 2.0.0-alpha.21 (freemocap_2.0.0-alpha.21_linux-x64-cuda.AppImage)
• OS: CachyOS (Arch-based), kernel 7.2.0-1-cachyos

Summary

The Electron main process caches the absolute path of the bundled freemocap_server executable — which lives under the AppImage's randomized /tmp/.mount_freemoXXXXXX/ mount point — in Electron's Local Storage (~/.config/freemocap/Local Storage/leveldb). On the next launch, a new random mount suffix is generated, so the cached path points to a directory that no longer exists, and server startup fails hard with:

Failed to start Python server: Error: Executable not found at:
/tmp/.mount_freemozFK1bv/resources/app.asar.unpacked/freemocap_server/freemocap_server

…even though the validation step immediately beforehand reports:

Validating all executable candidates...
  ✔ bundled: Valid          ← current mount, actually exists
Validation complete: 1/5 unique candidates are valid

So validation picks the correct candidate, but start() (dist-electron/main/index.js:162) uses the stale persisted path instead.

Steps to reproduce

1. Launch the AppImage once; close it.
2. Launch it again (mount suffix changes every run).
3. Server fails to start; UI shows no cameras/microphones.
4. strings ~/.config/freemocap/"Local Storage/leveldb"/*.log | grep mount_freemo shows only the dead path from the previous run.

Workaround that confirmed the diagnosis

Deleting Electron's Local Storage while the app is closed makes the next launch work (until the newly saved path goes stale again on the following launch):

rm -rf ~/.config/freemocap/"Local Storage"

Suggested fixes

1. Never persist paths that are derived from the AppImage mount point (or persist them per-mount-suffix and invalidate when $APPDIR changes).
2. If a persisted candidate fails fs.existsSync, fall through to the validated candidates instead of aborting startup.
3. Alternatively resolve the server executable relative to process.resourcesPath / $APPDIR at spawn time rather than caching it across sessions.

Related but separate issue: even once the server path resolves correctly, the bundled libstdc++.so.6 is too old for system libjack/libportaudio on Arch-based distros, crashing the server at import (see companion report).