fix(cua-driver): keep remote debugging enabled when a restart is needed

[f-trycua]

Stacked on #2899 (which is stacked on #2895). Review order: 2895 → 2899 → this.

The bug

setup_existing_profile_endpoint toggles "Allow remote debugging for this browser instance", polls ~6s for a loopback endpoint, and on timeout rolls the toggle back.

But that checkbox persists a preference. On a default user-data-dir, Chrome acts on it at next launch — not immediately. Measured on Chrome 151, enabling it by hand and leaving it enabled:

t=5s  listeners=0
t=10s listeners=0
t=15s listeners=0
t=20s listeners=0
t=25s listeners=0
DevToolsActivePort: absent

Then a restart, with no --remote-debugging-port flag:

LISTEN 127.0.0.1:9222  users:(("chrome",pid=111565,fd=142))
~/.config/google-chrome/DevToolsActivePort

So the rollback erased the setting moments before the restart that would have activated it. On such a profile the route could not succeed however reliably it navigated.

The change

Treat that state as armed rather than broken: keep the preference, close the temporary tab, and refuse with the one action the caller must take. The refusal carries restart_required: true plus the side-effect record, so a caller can branch on the field instead of parsing prose. Genuine failures still roll back unchanged — the new branch is guarded on enabled_remote_debugging && code == BrowserRequiresSetup.

What is verified, and what is not

Verified end to end on Chrome 151: on a non-default user-data-dir the same toggle opens a listener inside the existing 6s window, and setup now completes outright — navigate, match the exact checkbox, toggle, close the tab, attach:

{"action":"attached_existing_profile","prepared":true,
 "endpoint_ownership":{"detail":"new PID-owned approval listener correlated with exact setup"},
 "side_effects":{"enabled_remote_debugging":true,"closed_setup_page":true}}

That is the first time this route has worked at all on Linux, and it comes from #2899's navigation fix.

Not re-observed after the change: the restart-required branch itself. Reproducing it needs a default-user-data-dir profile with debugging currently off, and the profile I measured it on now has debugging enabled. The branch is reasoned from the measurement above. It is strictly safer than the previous behaviour regardless, since rolling back a persisted preference cannot be correct.

Related finding

Chrome ≥136 ignores --remote-debugging-port on the default user-data-dir (verified: same flag, same build, listener only appears with a non-default --user-data-dir). That makes this checkbox the only sanctioned route to CDP on a real user profile — which is why the rollback mattered enough to chase.

Tests: 229 passing.

Refs #2892

🤖 Generated with Claude Code

https://claude.ai/code/session_017zpeGjLTLSALtHsuxKLkNp