v1.8.7 regression: `keys` and `click` silently stop working (with extension v1.0.22) — and `click` still reports `clicked: true`

# v1.8.7 regression: `keys` and `click` silently stop working (with extension v1.0.22) — and `click` still reports `clicked: true`

## Summary

After upgrading the CLI from **1.8.6 → 1.8.7** while the Browser Bridge extension stayed at **v1.0.22**, all CDP-dispatched input stops reaching the page:

- `browser keys Enter` — no effect at all
- `browser click ` — returns `{"clicked": true, "hit": "target", "click_method": "cdp"}` but the page does not react

Reads (`open` / `extract` / `eval` / `find`) and DOM-level writes (`type` / `fill`) keep working, so the text really does land in the input — it just can never be submitted. Rolling the CLI back to 1.8.6 restores it immediately.

The **silent** part is the actual bug: `click` reporting success while dispatching nothing gives callers no way to detect the failure. If 1.8.7 requires extension ≥ v1.0.23, the CLI should say so (warn or refuse) rather than degrade quietly.

## A/B/A verification

Same machine, same Chrome, same extension build (v1.0.22) throughout. Only the CLI version changed. `daemon restart` between every step.

| Step | CLI | `type` | `keys Enter` on duckduckgo.com |
|---|---|---|---|
| 1. baseline | 1.8.6 | ✅ text lands | ✅ navigates to results |
| 2. upgrade | 1.8.7 | ✅ text lands | ❌ URL unchanged, title unchanged |
| 3. rollback | 1.8.6 | ✅ text lands | ✅ navigates to results |

Reproduced on two unrelated sites (duckduckgo.com and grok.com), so it is not site-specific. Two `daemon restart` cycles on 1.8.7 did not help.

## Reproduce

```bash
npm install -g @jackwener/opencli@1.8.7 # extension left at v1.0.22
opencli daemon restart

opencli browser t open "https://duckduckgo.com/"
opencli browser t wait time 6
opencli browser t type '#searchbox_input' "hello"
opencli browser t keys Enter
opencli browser t wait time 7
opencli browser t eval 'location.href'
# 1.8.7 → still https://duckduckgo.com/ (expected: /?q=hello...)
# 1.8.6 → https://duckduckgo.com/?ia=web&... title "hello at DuckDuckGo"
```

`click` on the same page shows the false-success shape:

```json
{"clicked": true, "target": "...", "matches_n": 1, "match_level": "exact",
"click_method": "cdp", "hit": "target"}
```

## Environment

- opencli 1.8.7 (bad) / 1.8.6 (good)
- Browser Bridge extension **v1.0.22** (not upgraded to v1.0.23 in any of the runs above)
- macOS 15 (Darwin 25.6.0), Chrome, Node v26.7.0

## Note

I have not tested 1.8.7 **with** extension v1.0.23 — it may well be fixed there, and #2098 (`stop SW wake events from wiping the lease registry, add owned-group ledger`) looks like it touches this area. Either way the failure mode seems worth addressing: the extension is Load-unpacked only (no Web Store auto-update), so a CLI upgrade will routinely land on an older extension, and today that combination fails silently with a success-shaped return value. A version-compat check at daemon startup, or at least making `click`/`keys` report dispatch failure, would make this self-diagnosing.

Start by reproducing the CLI 1.8.7 and extension v1.0.22 combination with the documented `keys` and `click` commands, then inspect the daemon startup and input-dispatch paths; issue #2098 may provide context. Compare behavior with CLI 1.8.6 and extension v1.0.23. Done means the incompatible combination is diagnosed clearly and input dispatch no longer reports a false success.

Written by the indexing model from the issue text.