[Feature]: add safety policy gates for write commands, domain scope, and daemon auth

### Feature Description

OpenCLI is becoming a powerful AI-native runtime for browser-backed and authenticated site adapters. That is useful, but it also means a local agent can reach sensitive browser capabilities such as cookies, broad tab/debugger automation, and `access: 'write'` commands.

I would like to propose a small safety policy layer around command execution and the local daemon. The goal is not to reduce OpenCLI's power, but to make that power easier to delegate safely to AI agents.

Suggested capabilities:

1. Global confirmation gate for `access: 'write'` commands
2. Runtime allowlist / denylist for sites and domains
3. Local daemon auth token shared only by the CLI and browser extension
4. Optional `--dry-run` / plan mode for write adapters, where feasible

### Use Case

As an OpenCLI user, I may want to let an AI agent run read-only commands freely, but I do not want it to accidentally post, delete, follow, message, buy, upload, or mutate state on authenticated accounts.

This matters especially because many useful OpenCLI adapters reuse browser login state. The current metadata already distinguishes `access: 'read'` and `access: 'write'`, but users still need a runtime enforcement mechanism so that agent delegation can be constrained without relying only on prompts or manual discipline.

Example scenarios:

- Allow `opencli hackernews top` or `opencli zhihu search` without confirmation
- Require explicit approval for `opencli twitter post`, `opencli instagram comment`, `opencli boss greet`, `opencli jd add-cart`, etc.
- Allow browser automation only for approved domains such as `github.com` and `notion.so`
- Deny obviously sensitive domains by default, such as banking, payment, healthcare, government, password-manager, and account-security surfaces
- Prevent arbitrary local processes from talking to the OpenCLI daemon unless they hold the session token

This would make OpenCLI safer for agent frameworks, shared machines, CI-like automation, and users who install the Browser Bridge extension in a dedicated Chrome profile.

### Proposed Solution

A possible design:

#### 1. Confirm writes by default

For every command whose manifest / registry metadata has `access: 'write'`, require confirmation unless one of these is true:

- The user passes an explicit `--yes` / `--confirm` flag
- The command is allowed by a policy file
- The process is non-interactive and `OPENCLI_ALLOW_WRITE=1` or a similar explicit opt-in is set

Suggested UX:

```bash
$ opencli twitter post --text "hello"
Command twitter/post is marked access: write.
This may mutate authenticated account state.
Proceed? [y/N]
```

Policy example:

```yaml
# ~/.opencli/policy.yaml
writes:
default: confirm
allow:
- chatgpt/ask
- claude/ask
deny:
- jd/add-cart
- twitter/delete
```

#### 2. Domain / site policy

Add a runtime policy checked before pre-navigation, cookie access, and browser-backed execution:

```yaml
browser:
allowedDomains:
- github.com
- openai.com
- notion.so
deniedDomains:
- bank.example
- paypal.com
- password-manager.example
unknownDomain: confirm
```

This would narrow the effective runtime surface even though the extension necessarily has broad host permissions.

#### 3. Local daemon auth token

Today the daemon is loopback-only and has Origin / header defenses, which helps against browser CSRF. A further hardening step would be a per-session local token:

- Daemon generates a random token at startup
- Token is stored in a mode-600 file under `~/.opencli/` or in OS keychain where practical
- CLI sends `X-OpenCLI-Token`
- Extension receives or reads the token through the documented setup path and sends it on WebSocket handshake / command flow
- Daemon rejects `/command`, `/status`, `/logs`, `/shutdown`, and `/ext` operations without the token

This would not defend against a fully compromised local user account, but it would reduce exposure to unrelated local processes on the same machine.

#### 4. Dry-run / plan mode for write adapters

Where feasible, write adapters could expose a dry-run summary before mutation:

```bash
opencli twitter post --text "hello" --dry-run
# would open twitter.com, target account @..., and submit a post with text length 5
```

This can be incremental. Not every adapter can support full dry-run, but the core could standardize the flag and adapters can opt in.

### Alternatives Considered

- Relying only on browser profile isolation. This is useful and should still be recommended, but it does not prevent accidental writes inside that profile.
- Relying only on AI-agent prompts. Prompts are not a reliable security boundary.
- Splitting each idea into separate issues. That may be useful later, but these features share the same goal: make OpenCLI delegation safer by turning existing metadata and daemon boundaries into enforceable runtime policy.

### Non-goals

- Prevent all attacks from a compromised local user account
- Remove broad extension permissions that are required by the current Browser Bridge design
- Block advanced users from automating writes; the goal is explicit opt-in, not prohibition
- Add heavy enterprise policy infrastructure before a simple local policy file is tried

Begin by tracing command execution, the existing access metadata, and the daemon operations named in the issue, including /command, /status, /logs, /shutdown, and /ext. Review how the browser extension handles navigation, cookies, and WebSocket commands. This issue needs to be narrowed into a scoped policy change with defined configuration, enforcement points, and tests before implementation is startable.

Written by the indexing model from the issue text.