grok: `ask` unusable — auth detection false-negative, and submit lands but no turn is detected

# grok: `ask` unusable — auth detection false-negative, and submit lands but no turn is detected

## Summary

On opencli **1.8.6**, `opencli grok ask` cannot complete a request against a logged-in grok.com session. Two failures, both consistent with the adapter having drifted from the current grok.com DOM:

1. **Auth false-negative** — `AUTH_REQUIRED` while the session is demonstrably logged in.
2. **Turn detection** — when auth does pass, the submit is dispatched but the adapter never sees the new turn.

Driving the same page with `opencli browser` primitives works reliably, so this is adapter-side.

> Tested on 1.8.6 specifically. 1.8.7 has a separate CDP input-dispatch problem (filed separately) that would confound results, so I kept this reproduction on 1.8.6.

## Environment

- opencli **1.8.6**
- Browser Bridge extension v1.0.22
- macOS 15 (Darwin 25.6.0), Chrome, Node v26.7.0
- grok.com logged in, free tier (`Fast` model)

## 1. Auth detection disagrees with itself

```bash
$ opencli grok status
- Status: Connected
Login: 'Yes' # <-- says logged in
Model: Fast

$ opencli grok whoami
error:
code: AUTH_REQUIRED
message: Grok __Secure-next-auth.session-token cookie missing # <-- says not

$ opencli grok ask "hello"
error:
code: AUTH_REQUIRED
message: Sign in to grok.com in your browser, then retry.
```

The session really is authenticated: the page renders the sidebar, chat history and account menu, and the browser-primitive workaround below completes full prompts against it, including a live-X-search run that returned 117 sources. `status` and `whoami` reading the same session and disagreeing suggests they use different signals, and that the cookie name `whoami` looks for is stale.

## 2. Submit dispatched, no turn detected

Before the auth check started failing in a given session, `ask` got one step further:

```
$ opencli grok ask "..." --new true --timeout 90
error:
code: COMMAND_EXEC
message: Grok submit button was clicked but no new user turn appeared.
```

This is a different failure from #1782 (`did not reach a clickable state`): there the button never became clickable, here the click is dispatched but the new turn is never observed. The `fix(grok): fall back to Enter-key dispatch` fallback (2026-05-31) is present in 1.8.6 and does not cover this.

## Working workaround

This completes every time on 1.8.6, including long DeepSearch-style runs (~1 min):

```bash
S=gk
opencli browser $S open "https://grok.com/"
opencli browser $S wait selector '[data-testid="chat-input"]'
opencli browser $S type 'div.ProseMirror[role="textbox"]' "your prompt"
opencli browser $S keys Enter
# poll until the last assistant bubble stops growing, then read it:
opencli browser $S eval 'var n=document.querySelectorAll("[data-testid=\"assistant-message\"]");n.length?n[n.length-1].innerText:""'
```

Two details that may help a fix:

- The composer is **tiptap/ProseMirror** (`div.ProseMirror[role="textbox"]`, `aria-label="Ask Grok anything"`). Enter submits only *after* text insertion — on an empty composer it just inserts a newline, so ordering matters.
- The page exposes stable test ids the adapter does not appear to use:
`chat-input`, `user-message`, `assistant-message`, `new-chat`, `attach-button`, `canvas-trigger`.
Turn detection keyed off `[data-testid="assistant-message"]` (count + text length until stable) was reliable across every run I did.

## Possibly relevant

`clis/grok` has had no functional change since 2026-06-06. The only grok touch in v1.8.7 is #2341 (`chore(grok): share site identity helpers`), which modifies `export-all.js`, `export.js`, `image.js`, `image.test.ts` — nothing in the ask/submit path. Related: #1782.

Happy to open a PR moving auth detection and turn detection onto the test ids above if that direction looks right.

Start in clis/grok and trace the ask, whoami, and submit/turn-detection entry points, comparing their session checks with the working browser primitives. Use the listed Grok test IDs, especially chat-input, user-message, and assistant-message, while reproducing on opencli 1.8.6. Done means authenticated sessions pass whoami and ask, and submitted prompts reliably produce a detected user turn and response.

Written by the indexing model from the issue text.