[BUG] Chrome Extension MCP: native host binary copy fails with EBUSY whenever the old host is running, leaving it stale

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version

### What's Wrong?

On Windows, the desktop app copies `chrome-native-host.exe` out of the installed package into `%APPDATA%\Claude\ChromeNativeHost\` at startup. If a `chrome-native-host.exe` from a previous run is still alive — which is normal, since Chrome keeps native messaging host processes running — the destination file is locked, `fs.promises.copyFile` fails with `EBUSY`, and the copy is abandoned with no retry and no fallback.

This has fired **219 times over 20 days** on my machine, roughly 10 times a day, on every app version in that window (1.34493.1.0 through 1.49585.0.0).

The concerning part is not the log line itself but the consequence: after an app update, the native host binary on disk can silently remain the *old* version, because the only code path that refreshes it is the one that just failed. The error is logged and execution continues as if nothing happened.

### What Should Happen?

`copyFile` onto a running executable is expected to fail on Windows; the app should use the standard pattern instead of treating it as a hard failure:

- Write to a temporary name in the same directory, then `rename()` over the target. `rename` succeeds against a locked destination in cases where `copyFile` does not, and is atomic.
- If the rename also fails, fall back to `MoveFileEx(..., MOVEFILE_DELAY_UNTIL_REBOOT)`, or retry after terminating/waiting for the old host process.
- Failing all of that, the app should at least retry with backoff and surface a real warning that the Chrome native host is stale, rather than logging an error and proceeding.

### Error Messages/Logs

```
2026-09-09 21:33:01 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile ':\Program Files\WindowsApps\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe' -> '\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'
at async Object.copyFile (node:internal/fs/promises:1327:10)
at async jjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2245502)
at async Njn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2246141)
at async Fjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2246860)
at async Ijn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2247723)
at async Vjn (app://\.vite\build\index.chunk-BRN0sgAk.js:13:2249079) {
errno: -4082,
code: 'EBUSY',
syscall: 'copyfile',
path: ':\\Program Files\\WindowsApps\\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\\app\\resources\\chrome-native-host.exe',
```

Note the source path is inside `WindowsApps\Claude__...`, so the source changes with every app update — meaning every update is an opportunity for the destination to be left stale.

It reproduces continuously, not just at first launch. Occurrences per day (recent):

```
9 2026-09-02
7 2026-09-03
15 2026-09-04
17 2026-09-05
10 2026-09-06
8 2026-09-07
13 2026-09-08
11 2026-09-09
```

219 total across `main1.log` + `main.log`, first seen 2026-08-21 on app version 1.34493.1.0.

### Steps to Reproduce

1. Windows, Claude desktop app with the Chrome extension connected.
2. Open Chrome with the extension active, so `chrome-native-host.exe` is running. (`Get-Process chrome-native-host` to confirm.)
3. Restart the Claude desktop app, leaving Chrome open.
4. Check `%LOCALAPPDATA%\Claude\Logs\main.log` — the `EBUSY` error above is logged and `%APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe` is not refreshed.

### Is this a regression?

No, this never worked — it is present in the oldest logs I have.

### Additional Information

- Claude desktop for Windows **1.49585.0.0** (also 1.34493.1.0, 1.37937.x, 1.40609.x, 1.44121.x, 1.46388.x)
- Claude Code **2.1.216**
- Windows 11 Pro build 26220
- Installed from the Microsoft Store (`Program Files\WindowsApps\...`), which may matter: the package directory is read-only and versioned per update.

The report identifies the packaged desktop entry app:///.vite/build/index.chunk-BRN0sgAk.js and the Windows main.log, but names no repository source file or test. Start by locating the source corresponding to that stack entry and reproduce with Get-Process chrome-native-host while checking the copied binary and main.log; done means an updated host is not silently left stale when the old process is running.

Written by the indexing model from the issue text.