browser: SESSION_BUSY needs hosted parity; data: storage needs a clear contract

[ankitranjan7]

Why this issue exists

This came from the local:session-concurrency eval. The original issue combined two failures:

1. Same-session contention did not surface as Webcmd SESSION_BUSY in the weak run.
2. data: documents could not use localStorage, which made the assigned fixture harder for agents to drive.

Source reports:

• /Users/ankitranjan/Work/agentrhq/evals/results/run-20260820T085734Z/report.md
• /Users/ankitranjan/Work/agentrhq/evals/results/run-20260820T103952Z/report.md

Current Webcmd state

As of origin/main 22974697bb3fe784bad5ef5a208f2d6ee5a272a8 (webcmd-v0.7.4-2-g2297469):

• Local Webcmd has a structured SESSION_BUSY error.
• The error says another holder is already driving the session and tells the agent to wait, then retry the same command.
• The daemon has session lease coverage and browser run help says a second overlapping run returns SESSION_BUSY.
• Browser-run now maps data: / about:blank storage failures to BROWSER_RUN_INVALID_INPUT with the hint: data: pages cannot use localStorage.
• A maintainer comment asks to make sure the hosted version is fixed as well.
• There is still no evidence in this issue that hosted Webcmd returns the same SESSION_BUSY behavior and same data-page limitation guidance.

Observed agent behavior

The failed run showed the confusion clearly:

• The agent created separate sessions but did not create CLI-level contention.
• It attempted overlap inside one browser run using two page.evaluate(applyUpdate) calls.
• No SESSION_BUSY envelope appeared because the second operation was not a second Webcmd invocation.
• The agent concluded the structured busy response did not exist in page code.
• The count ended at 3, not the intended wait/retry count of 2.

The successful run eventually did the correct Webcmd flow:

• Started one browser run holding a session.
• Issued a second webcmd --session <same-id> browser run while the first was live.
• Received structured SESSION_BUSY naming the holder pid.
• Waited, retried the same second command, and verified count 2.

What went wrong

The root local SESSION_BUSY behavior appears fixed, but this issue is not fully stale because the cross-mode guarantee is still open.

The agent behavior also shows why the CLI must carry the concept. Agents naturally try to solve concurrency inside the page unless Webcmd makes it obvious that session contention is between CLI invocations.

The data: part is now a named limitation rather than a silent mystery. That may be good enough, but senior review should decide whether eval fixtures should avoid data: + localStorage or Webcmd should provide a stronger workaround.

Solution directions

Product-first options:

1. Verify hosted Webcmd returns structured SESSION_BUSY before browser work starts when a session is already held.
2. Verify hosted error text/hints match local behavior closely enough for agents to recover.
3. Decide whether data: + localStorage should remain unsupported with a clear error, or whether eval fixtures/product behavior should change.
4. Keep skill changes minimal: one line at most saying SESSION_BUSY is produced by a second webcmd --session <id> ... invocation, not by page.evaluate.

Open questions for senior review

• Is local SESSION_BUSY complete enough to close the original local bug and leave only hosted parity?
• Should hosted parity be tracked here or split into a separate Cloud issue?
• Should eval tasks avoid data: pages that require localStorage, now that the CLI explicitly rejects that storage path?

Acceptance criteria

• Local and hosted both return structured SESSION_BUSY for overlapping commands on the same session.
• The busy error tells the agent to wait and retry the same command.
• --force is presented only as a last resort for a dead holder.
• data: / about:blank storage failures produce a clear typed error or the storage path is supported intentionally.

Non-goals

• No in-page mutex as the Webcmd safety mechanism.
• No eval-specific workaround text.
• No silent queued second driver on the same session.

[ankitranjan7]

Partial in #381

• Overlapping browser run now prints structured SESSION_BUSY on stdout and stderr; hint is wait-and-retry.
• data: / about:blank localStorage failures name that limitation.

Not done here: a dedicated overlapping-run daemon test, or making localStorage actually work on data: documents.

[beubax]

Make sure you fix this issue for the hosted version as well.