[Bug]: chrome.tabs.update rejected with "Navigation rejected." on Chrome 152 when the extension detaches the debugger right before navigating

### Description

### What happened

Any OpenCLI adapter that only navigates (no network capture) fails on Chrome 152 with:

```
ok: false
error:
code: UNKNOWN
message: Navigation rejected.
exitCode: 1
```

`Navigation rejected.` is Chrome's own error — the string is present in the Chrome 152 binary — i.e.
`chrome.tabs.update(tabId, { url })` is being rejected.

### Environment

- macOS (Darwin 25.2.0), arm64
- Google Chrome 152.0.7977.83
- OpenCLI CLI 1.8.6 (OpenCLIApp 0.1.37)
- Browser Bridge extension 1.0.24 (ildkmabpimmkaediidaifkhjpohdnifk)

### Root cause

In the extension bundle (`dist/background.js`, v1.0.24), `handleNavigate` does:

```js
if (!hasActiveNetworkCapture(tabId)) {
await detach(tabId); // chrome.debugger.detach({ tabId })
}
await chrome.tabs.update(tabId, { url: targetUrl }); // rejected by Chrome 152
```

With `--trace` (`on` / `retain-on-failure`), `execution.js` calls `page.startNetworkCapture()`, so
`hasActiveNetworkCapture(tabId)` is true and the `detach()` is skipped → navigation succeeds. With `--trace` off, the
detach runs and the immediately following `chrome.tabs.update` is rejected.

### Expected

`navigate` succeeds regardless of `--trace`.

### Actual

`chrome.tabs.update` rejects navigation with `Navigation rejected.` whenever the debugger was detached immediately
before. The failure is persistent per profile: once a profile's automation tab is left in the "previously attached"
state, every plain invocation keeps failing.

### Workaround

Keep a network capture active before navigating (what trace mode does internally):

```js
await page.startNetworkCapture?.();
await page.goto(probeUrl);

### Steps to Reproduce

1. Use any adapter that calls `page.goto(...)` and does NOT enable network capture.
2. Run it without trace mode — it fails:
```
opencli --profile ... --format json
```
→ exit 1, `message: Navigation rejected.`
3. Run the SAME command with trace mode — it succeeds:
```
opencli --profile ... --format json --trace retain-on-failure
```
→ exit 0, command completes.
4. Run it again without trace mode → it fails again.

A/B on the same profile, back to back:

| run | flags | result |
|-----|-------|--------|
| 1 | (none) | FAIL |
| 2 | (none) | FAIL |
| 3 | `--trace retain-on-failure` | SUCCESS |
| 4 | (none) | FAIL |

The only variable is whether the debugger stays attached (trace mode calls `page.startNetworkCapture()`), which makes
the extension skip its pre-navigation `detach()`.

[repro.sh](https://github.com/user-attachments/files/32085162/repro.sh)

### Expected Behavior

`navigate` / `page.goto(...)` should succeed regardless of whether `--trace` is enabled. `chrome.tabs.update` should
not be rejected merely because the debugger was detached immediately before it.

### OpenCLI Version

1.8.6

### Node.js Version

22.x

### Operating System

macOS

### Logs / Screenshots

```shell

```

Start with repro.sh or the documented A/B commands, then inspect handleNavigate in dist/background.js and the page.startNetworkCapture path in execution.js. Confirm that navigation succeeds both with and without trace mode, including repeated runs on the same profile, without a Navigation rejected error.

Written by the indexing model from the issue text.