fix(windows): stop pythonw backends during desktop update

[xuezhaolan]

Summary

• Extends the Windows desktop update straggler cleanup to stop detached Hermes backends running under pythonw.exe/python.exe, not just hermes.exe.
• Scopes the Python-process sweep to this install's venv path so unrelated Python or Hermes processes are not touched.

Rationale

The Windows desktop/gateway backend can run as pythonw.exe -m hermes_cli.main ... gateway run. If that process survives handoff, it can keep files in venv locked and make the update/rebuild fail with Access denied even after taskkill /IM hermes.exe succeeds.

Closes #70026

Test Plan

• git diff --check -- apps/bootstrap-installer/src-tauri/src/update.rs
• targeted static assertions for the updated call site and venv-scoped PowerShell predicate
• added-line secret/security scan for this diff
• independent Codex review: PASS

Note: Rust toolchain is not installed in this sandbox (cargo missing), so cargo fmt/cargo test could not be run locally.

[alt-glitch]

This was generated by AI during triage.

Related: #65935 and #70026. This is a focused bootstrap-installer repair for the pythonw lock case, while #65935 covers the same update path plus base-interpreter trampoline and broader venv-holder detection. Please consolidate the overlapping bootstrap changes rather than treating either PR as a duplicate.

[teknium1]

Thanks for narrowing the process sweep to the install venv rather than killing every Python process.

Problems

• The new sweep cannot run for the reported Python-only holder case. wait_for_install_locks_free() only calls force_kill_other_hermes() after its probes remain locked (apps/bootstrap-installer/src-tauri/src/update.rs:638-687), but those probes are venv/Scripts/hermes.exe plus app.asar (apps/bootstrap-installer/src-tauri/src/update.rs:693-713, 856-861). A process locking only python.exe, pythonw.exe, or a loaded .pyd exits at the clear-probe path before this sweep.
• Current main now kills desktop-owned backend trees and then aborts handoff when the venv-holder scan finds another process (apps/desktop/electron/main.ts:2738-2765, 2926-2936). The update command independently rejects the same holder class (hermes_cli/update_cmd.py:3117-3132). This fallback needs to be reconciled with that safety boundary.

Suggested changes

• Wire the fallback to an actual Python-holder trigger, or retain the current refusal path for external holders; do not rely only on the Hermes-shim/app.asar probes.
• Add behavioral coverage for the selected trigger and venv-prefix scoping.

Automated hermes-sweeper review.