# The second tab was not concurrent

We already had one browser tab per agent. That looked like concurrency on the
board: `research` belonged to one task, `inbox` to another, and neither could
navigate the other's page.

Then we timed two 200 ms operations.

They took about 400 ms.

The tabs were isolated, but the daemon still accepted one connection, finished
its browser call, sent the reply, and only then accepted the next connection.
The browser driver added a second queue of its own: every synchronous Patchright
call ran through one worker thread. A named tab prevented corruption; it did not
let the second task move.

The fix was to choose one place that owns concurrency. The daemon now owns one
asyncio event loop and one async Patchright runtime. Each request is an asyncio
task. The browser core locks the page for that request's bound tab, not the whole
browser. Two requests for `research` still run in order. A request for `research`
and one for `inbox` can overlap.

Claims stay outside that scheduling decision. Before a task touches a page, a
small registry lock decides whether its caller owns the tab. Two callers racing
for `main` therefore cannot both pass an asynchronous check-then-write gap: one
records the claim and the other receives exit code 4. The winner also records a
request id in the tab metadata. A `finally` block removes that exact request id
after success, failure, or cancellation without deleting the longer-lived tab
owner.

We kept the native transports rather than hiding blocking Windows pipes behind
an unbounded default executor. POSIX connections enter the event loop directly.
Windows accept, authentication, read, and write calls cross a dedicated bounded
worker pool and submit to the same async dispatch path. Both sides cap admitted
clients, request bytes, read time, and reply time. Concurrency without those
bounds would only trade one global queue for an unlimited pile of tasks.
On Windows, a successful whole-browser `close` also waits for the exact daemon
PID that served it to exit. The next command can therefore cold-start against a
new named pipe instead of reaching the old daemon during its shutdown window.
Because closing a Windows listener does not interrupt an `accept` already
blocked in a worker, shutdown authenticates one internal wake connection and
discards it before joining the bounded worker pool.

The useful test is still the original stopwatch. Two independent 200 ms
operations go through the real local socket and overlap. The same-tab test takes
roughly 400 ms and proves ordering remains. A third test closes the client before
the reply, then checks that the request lease and active operation are gone while
the tab's durable owner is still present.

The lesson was not "replace threads with asyncio." It was that isolation and
concurrency are different properties. A tab map gave us isolation. Only moving
the daemon and the driver onto the same owned async runtime made the second tab
concurrent.