[Bug]: [Windows Installer] NSIS "still running" check matches the installer process itself → infinite loop, installation impossible

## Summary

The Windows NSIS installer (`QwenPaw-Tauri-2.0.1-Windows-setup.exe`) shows a
"QwenPaw Desktop is still running" error dialog on every launch, even when
**no QwenPaw application process exists on the system**. The dialog offers
only "Retry" and "Cancel"; clicking Retry re-triggers the same check, which
again matches the installer's own process → **unresolvable infinite loop**.
The only way out is Cancel (abort installation).

## Environment

| Item | Value |
|------|-------|
| OS | Windows 11 24H2 (also reproduced on Win 10 22H2) |
| Installer | `QwenPaw-Tauri-2.0.1-Windows-setup.exe` (official download) |
| Install target | `D:\QwenPawDesktop` (also fails with default path) |
| Privilege | Elevated (Administrator) PowerShell |
| Prior QwenPaw install | Yes (v1.x via Electron), fully uninstalled; only `%USERPROFILE%\.qwenpaw` data dir remains |

## Steps to Reproduce

1. Ensure **no** `qwenpaw.exe` or `qwenpaw-backend.exe` process is running
(verified via Task Manager and `Get-CimInstance Win32_Process`).
2. Double-click `QwenPaw-Tauri-2.0.1-Windows-setup.exe`
(or run `& "...\setup.exe" /D=D:\QwenPawDesktop` from elevated PS).
3. Installer window appears → immediately shows the error dialog:
> *"QwenPaw Desktop is still running. Please close it and click Retry."*
4. Click **Retry** → same dialog reappears. Repeat indefinitely.
5. Click **Cancel** → installation aborts.

## Evidence

While the error dialog was displayed, I ran the following in a **separate**
elevated PowerShell:

```powershell
# Exact match – the two names the bundled stop-backend.ps1 checks:
Get-CimInstance Win32_Process -Filter "Name='qwenpaw-backend.exe' OR Name='qwenpaw.exe'"
# → (empty, no results)

# Broad match – anything with "qwen" or "paw" in the name:
Get-Process | Where-Object { $ _.Name -match 'qwen|paw' } | Select Id, Name, Path

Output:

Id Name Path
-- ---- ----
3748 QwenPaw-Tauri-2.0.1-Windows-setup D:\setup\QwenPaw-Tauri-2.0.1-Windows-setup.exe

The only process matching "QwenPaw" is the installer itself.
Additional checks (all negative):
Get-NetTCPConnection -LocalPort 8088 → empty (no backend listening)
Get-Process python*, py* → empty
taskkill /F /IM qwenpaw-backend.exe → "ERROR: The process was not found"
taskkill /F /IM qwenpaw.exe → "ERROR: The process was not found"
D:\QwenPawDesktop contains zero .exe files (target dir is empty)
%LOCALAPPDATA% has no QwenPaw-related directories
Root Cause Analysis
I extracted and reviewed the installer's bundled qwenpaw-stop-backend.ps1.
That script only checks for qwenpaw-backend.exe and qwenpaw.exe by exact
image name, scoped to $InstallDir — it would correctly exit 0 here.
The problematic check is a different, earlier "running application" gate
in the NSIS main script (likely using the nsProcess / FindProc plugin or
a window-title match). This check appears to match on a substring such as
"QwenPaw" against all running process names or window titles. Since the
installer's own process name is QwenPaw-Tauri-2.0.1-Windows-setup.exe
(and its window title is "QwenPaw Desktop Setup"), it matches itself.
This creates a self-referential deadlock:

installer starts
→ running-app check scans processes
→ finds "QwenPaw-Tauri-...-setup.exe" (itself)
→ shows "still running" dialog
→ user clicks Retry
→ check runs again → finds itself again → dialog again
→ ∞

This also explains why:
Killing all Python/backend processes doesn't help (they aren't the match).
Deleting .lock / .pid files doesn't help (irrelevant to this check).
The bug is 100% reproducible on any machine where no prior QwenPaw
desktop app is installed — the installer is always its own false positive.
Users who had a previous QwenPaw desktop install may not hit this if the
old qwenpaw.exe was genuinely running and got killed first, masking the
self-match on retry.