fix(daemon): serialise the first attach so Chrome gets one consent prompt

[sanketsudake]

Closes the defect that froze a real Chrome session during the RFC work.

What happened

Ensure checked for a running daemon, found none, and spawned one — with nothing making that path single-file:

if c := TryConnect(sockPath); c != nil { return c, nil }
_ = os.Remove(sockPath)
cmd := exec.Command(exePath, "__daemon", sockPath)   // every caller gets here

Several chrome-cdp processes starting at once each found nothing and each spawned a daemon. Every spawned daemon attaches to Chrome, and every attach raises its own "Allow remote debugging?" prompt.

That prompt is browser-modal, so stacked prompts are not a slower version of one prompt: the visible dialog need not be the one holding input, and the browser looks frozen with no button that responds. That is exactly what was reported — "Chrome was frozen, I was not able to click on any of the option".

It happened because several review agents each ran the built binary to verify exploits, and their attaches raced. The daemon exists so the prompt happens once per session; nothing was making the first attach single-file.

The unlink is the other half. Outside a lock, a late caller's os.Remove(sockPath) can delete a socket a sibling daemon has just bound — orphaning a live daemon that no client can ever reach.

The fix

An exclusive flock covers spawn-and-wait, with a re-check inside it so callers that queued behind the holder find the daemon it started rather than duplicating it. That re-check is what makes N callers converge on one daemon and one prompt.

The wait is deliberately unbounded. The holder may be waiting out a prompt the user hasn't clicked yet, and blocking behind that is the correct outcome — spawning our own would add another prompt to the pile, which is the failure this exists to prevent.

The lock file is never unlinked: removing it would let a later caller lock a different inode and defeat the exclusion entirely.

The regression test

Eight concurrent Ensure calls against a substitutable spawn it can count. Proven red by disabling only the lock (keeping the test seam):

spawn_test.go:76: 8 daemons were spawned for 8 concurrent callers, want exactly 1
                  — each spawn attaches to Chrome and raises its own consent prompt

With the lock: exactly 1.

The fake spawn binds its socket 150 ms after being asked, so the window between "spawned" and "connectable" is real rather than instantaneous and every caller must still converge on the one listener.

Diagnostics

did you click Allow in Chrome? isn't much help when the reason you haven't is that you can't see it. The connect timeout now says the prompt may be hiding behind the window and that Chrome accepts no other input until it is answered — so a user seeing a frozen browser has the actual next step. skills/drive-chrome-cdp/SKILL.md says the same, since it previously warned about the wedge without saying the prompt is browser-modal.

Testing

gofmt, go vet, go test -race ./... all clean including the live-Chrome suite. No live Chrome was driven to develop this — the tests substitute the spawn, so the concurrency is exercised without attaching to a real browser.

Note for reviewers

A long t.TempDir() path breaks a Unix socket bind on darwin (sun_path caps near 104 bytes, and the dir embeds the test name — it failed with a bare bind: invalid argument). The test uses a short temp dir and says why, in case another socket test hits it.

[sanketsudake]

The reproduction changed the diagnosis — this PR is necessary but not sufficient

I ran a controlled reproduction against a real Chrome. It contradicted the theory this PR was built on, so I've added RFC-0013 to the branch recording what actually happens.

Stacked prompts are real and this PR fixes them — 8 concurrent callers produced 8 daemons before, 1 after. But a single unanswered prompt wedges Chrome just as thoroughly. Serialising the spawn removes one cause, not the failure.

The mechanism, measured

Probe	While consent is pending
TCP connect to 127.0.0.1:9222	succeeds immediately
GET /json/version	404 in under a millisecond
WebSocket upgrade to the browser endpoint	hangs — never completes, never refuses

The hang is the whole thing. Chrome doesn't reject the connection while it waits for the user; it holds the upgrade open and says nothing. The client has no error to classify — only silence — which is why this surfaces as an undifferentiated timeout.

Three defects follow, each independent of concurrency:

1. The daemon abandons the prompt it raised. It dials, the upgrade hangs, the dial times out in ~10s, the daemon writes its error and exits. The modal is left on screen with nothing behind it — clicking Allow then grants consent to a connection that no longer exists. Observed directly: the daemon process was gone 25 seconds after the prompt appeared.
2. 10s is not a human timescale for a browser-modal dialog that can sit behind the window. A user who hasn't clicked it usually hasn't seen it.
3. doctor reports readiness it never verified. It read the port file and said "debug endpoint reachable — Path B attach ready", handing back a ws:// URL, while every actual connection was hanging.

A correction

I initially read /json/version returning 404 as a consent-pending signal. That was wrong — it returns 404 in this connection mode whether or not consent has been granted, because the chrome://inspect toggle path exposes the WebSocket without the HTTP JSON API. Any detection built on that would have been wrong too. Recorded in the RFC so it isn't rediscovered.

Also worth stating plainly

My own probing made the user's wedge worse. Each WebSocket upgrade attempt is another connection request and raised another prompt. The RFC's test plan is deliberately built on net.Listen stubs — a listener that accepts and stalls reproduces the pending state exactly — because reproducing this by hand wedged a real browser twice and must not become the regression test.

What still ships here

The serialisation, its 8-to-1 regression test, and the improved timeout message. RFC-0013 proposes the rest: wait for the consent instead of abandoning it, classify the pending state distinctly, make doctor probe, and lead the docs with --remote-debugging-port — the path that never prompts at all.

[sanketsudake]

Superseded by #18, which now targets main and contains these commits plus the RFC-0013 implementation built on them.

Keeping them together because the reproduction showed they are one fix, not two: serialising the spawn stops N prompts, but a single unanswered prompt wedges Chrome just as thoroughly. Reviewing the spawn lock without the consent lifecycle would review half a fix.