[Bug]: Chrome close confirmation blocks UI adapter teardown on macOS

### Description

When an OpenCLI UI adapter opens a background automation window and later tries to clean it up, Chrome shows a browser-level confirmation dialog asking whether the window should be closed (localized Chinese UI: “是否关闭”).

The CLI remains blocked until the user manually confirms the dialog. The site action may already have succeeded, so an agent cannot safely decide whether to retry while the command is stuck.

This was observed while publishing a multi-part X/Twitter thread with `twitter/post` and `twitter/reply` using `--window background`.

### Steps to Reproduce

1. Start Chrome with the OpenCLI Browser Bridge extension connected.
2. Confirm the bridge is healthy with `opencli doctor`.
3. Log in to X/Twitter.
4. Run a UI-backed command such as:

```bash
opencli twitter post "test post" -f json --window background
```

5. Wait for the adapter to finish the site action and clean up its automation window.
6. Chrome displays a confirmation dialog asking whether to close the window.
7. Leave the dialog untouched: the CLI remains blocked.
8. Manually confirm the dialog: the command can then continue or exit.

### Expected Behavior

OpenCLI-owned automation windows should be released without requiring user interaction. If Chrome presents a close confirmation, OpenCLI should handle it deterministically or avoid triggering it. The CLI should return promptly after the adapter result is known.

### Actual Behavior

The browser-level close confirmation blocks teardown indefinitely until the user clicks it manually.

In an agent-driven multi-part Twitter workflow, this made follow-up automation unreliable and created an ambiguous state: earlier posts had succeeded, but the process did not complete normally.

### Environment

- OpenCLI: `1.8.6`
- Browser Bridge extension: `1.0.22`
- Node.js: `22.23.1`
- Chrome: `150.0.7871.129`
- macOS: `26.5.2` (build `25F84`)
- Connected Browser Bridge profile: `rtx9knyy`
- Adapter: `twitter/post` and `twitter/reply`
- Window mode: `background`

### Notes

The exact root cause is not yet confirmed. The dialog appears during automation-window teardown; it may involve a page close guard or the extension’s window/lease cleanup path.

Possibly related lifecycle reports:

- #1964 — orphaned automation windows and system popups
- #1791 — automation window/tab-group cleanup
- #1082 — Twitter command hangs after browser close

A possible fix area is the cleanup path around `page.closeWindow()` / lease release: detect and handle a pending close dialog before removing the owned window, or reuse the adapter container without closing it between sequential commands.

Start by reproducing the issue with opencli doctor and the twitter/post or twitter/reply command using --window background. Trace the teardown path around page.closeWindow() and lease release. Done means an OpenCLI-owned window can be cleaned up without a browser confirmation blocking the CLI, and the command returns promptly after the adapter result is known.

Written by the indexing model from the issue text.