The root cause of "the TUI keeps crashing" on Linux, Windows, and Intel Macs: builds since the OpenTUI 0.4.2 upgrade shipped a two-versions-old native render library next to new code, and on upgraded machines the old library could survive in ~/.empryo/native indefinitely. Both halves are fixed, and a set of production-hardening guards landed with them.

• TUI startup crash (`Symbol "dumpOutputBuffer" not found`). The build now verifies every platform's native OpenTUI library against the exact JS version and fetches the right one from the registry when the local copy is stale — a lockstep gate in the release pipeline makes shipping a skew impossible. If you hit this: reinstall, or rm -rf ~/.empryo/native and relaunch.
• Upgrades fully refresh the runtime. A version marker forces ~/.empryo/{native,wasm,opentui-assets} to be rebuilt whenever the binary version changes, files are swapped atomically (a running Empryo never sees a torn library), and dropped files can't linger.
• Addons survive upgrades. Installing a new version no longer wipes opt-in addons (proxy, Neovim) — they stay installed and linked.
• Installs verify themselves. The installer now runs the freshly installed binary before declaring success — wrong-CPU downloads (SIGILL) and corrupt archives fail loudly with the exact fix, and EMPRYO_ARCH=x64-baseline can force the no-AVX build explicitly.
• Updates behave. Beta users are offered the final release of the same version, and empryo update no longer times out at 60 seconds and orphans a half-finished installer.

• Build-time smoke tests run every host-compilable binary before packaging.
• TUI renderer-init failures now write a crash report and, when the cause is a stale native runtime, say exactly that instead of blaming your terminal.