fix(update): stream update child output to the live log (PYTHONUNBUFFERED)

[joelbrilliant]

Problem

When the desktop app updates itself (Tauri Hermes-Setup --update hand-off, or the in-app POSIX path), the spawned hermes update is a Python CLI writing to a pipe, so CPython block-buffers its stdout. Nothing reaches the live log until 8 KB accumulate or the process exits.

The worst case is the pre-update backup (updates.pre_update_backup: true): it can zip multi-GB archives for minutes while the updater UI still shows the previous line. On my install the updater sat on [update] waiting for Hermes to exit… for over 3 minutes while a 4.2 GB pre-update-*.zip was being written:

# ~/.hermes/logs/bootstrap-installer.log (frozen from 19:23:31Z)
2026-07-14T19:23:30Z INFO Hermes Setup starting mode=Update
2026-07-14T19:23:31Z INFO bootstrap.log: [update] waiting for Hermes to exit… stage=update

# meanwhile:
-rw-r--r-- 4185664739 Jul 15 05:26 ~/.hermes/backups/pre-update-2026-07-15-052331.zip

A user reads that silence as a hang and cancels — and because the child is not killed with the updater, the orphaned hermes update keeps mutating the install headless. The same silent-stage behaviour applies to the desktop's in-app POSIX update path.

Fix

Set PYTHONUNBUFFERED=1 at both spawn sites so the child streams line by line:

• update_child_env() in apps/bootstrap-installer/src-tauri/src/update.rs (covers the hermes update and hermes desktop --build-only stages of the Tauri hand-off)
• the env handed to runStreamedUpdate in applyUpdatesPosixInApp (apps/desktop/electron/main.ts)

With this, the "Creating pre-update backup…" line (and everything after) appears in the live log the moment it is printed, so a long backup reads as progress instead of a freeze.

Also in this PR

cargo test for the installer never passed on macOS: lock_probe_paths_include_desktop_app_payload asserts a probe ends with resources/app.asar, but the macOS payload lives under Contents/Resources/ and Path::ends_with is case-sensitive. The assertion now accepts both layouts.

Validation

• cargo test --lib (apps/bootstrap-installer/src-tauri): 28 passed, 0 failed on macOS arm64, including a new unit test asserting PYTHONUNBUFFERED=1 is present in the update child env
• npx tsc -p apps/desktop --noEmit: clean
• Reproduced the buffering silence on a real install (macOS 15 / Darwin 25.5.0) before the change; logs above

🤖 Generated with Claude Code

[teknium1]

Verified the reported buffering path on current main. apps/bootstrap-installer/src-tauri/src/update.rs:642-650 pipes the child streams and passes update_child_env() to both update and rebuild launches; that environment currently lacks PYTHONUNBUFFERED at :730-742. The POSIX in-app path has the same shape: apps/desktop/electron/main.ts:2649-2655 uses pipe stdio and :2718-2721 builds the shared child environment used at :2767-2771 and :2789.

The proposed setting matches the established gateway update-streaming behavior in gateway/slash_commands.py:4622-4631 and :4654-4656. The macOS test adjustment also matches the production macOS payload suffix in apps/bootstrap-installer/src-tauri/src/update.rs:554-558.

No blocking issues found. The current-main hunk contexts remain unchanged, so this appears mechanically salvageable.

Automated hermes-sweeper review.

[joelbrilliant]

Thanks for the verification. Rebased onto current main (clean, hunk contexts unchanged as you noted) and re-ran the installer suite on the rebased branch: 28 passed including the new env unit test. Good pointer on gateway/slash_commands.py already doing this for its own update streaming — same rationale, now consistent across all three update surfaces.