… state

The counterpart to the Atlas `deferred` transport. Elicitation is what makes
this process stateful — a suspended `elicitation/create` pins an McpServer in
one pod's heap until the answer arrives, which is why the hosted deployment
needs sessions, ingress affinity keyed on the caller's credentials, and a cap on
live sessions. Deferred removes the suspension instead of routing around it.

    call 1  askBrowserStackAI(product, query)
            -> status "needs_approval", run_id, perm_id, the pending ask
    call 2  askBrowserStackAI(run_id, perm_id, decision)
            -> POST the decision, reattach, return the remainder

Nothing is held between the two, so either call can be served by any pod.

`relayMode()` now answers per DEPLOYMENT rather than per client:

  REMOTE_MCP + opt-in  -> "deferred"
  REMOTE_MCP, no opt-in-> "remote_mode"  (unchanged: read-only)
  stdio                -> elicitation, exactly as before

stdio deliberately keeps eliciting. One process, nothing to pin, and the CLIENT
renders the prompt so the model cannot fabricate the answer. A local install
would pay the two-call cost for nothing.

THE TRADE, stated because it is real and inverts an existing test. On the
deferred path approval rides the client's own permission prompt on call 2, not
an elicitation, so client elicitation support stops being the gate. Claude
Desktop declares none but does prompt before a tool call, and gains writes it
could never have had. The same fact the other way: a client configured not to
prompt (`--permission-mode auto`) now approves with no human, where elicitation
failed closed by construction. The test that asserted "the opt-in does NOT force
the relay onto a client that cannot be asked" is inverted on purpose, and says
so at length rather than being quietly deleted.

`perm_id` travels to the caller and back rather than being remembered here. The
first sketch kept a `Map<runId, permId>` in the module, which would have made
call 2 depend on reaching the same pod — reintroducing, in this file, the exact
statefulness the change exists to remove. It also names WHICH ask is being
answered, which matters as soon as a task needs more than one: a resumed run
that hits a second gate parks again rather than answering it for the user.

Ordering inside the resume is a safety property: the decision is POSTed BEFORE
the reattach, so a failed reattach cannot leave the gate waiting on an answer we
already have. A lost reattach costs the caller the answer; a lost decision would
cost them the run. An undelivered decision (0 / 404 / 409) is reported as
undelivered and never as an approval, and does not reattach.

A read-only task still costs ONE call: with no ask, the ordinary result comes
back through the same `buildResult` the streaming path uses, so an entitlement
refusal, a 401 and a plain failure read identically whichever transport produced
them.

653 tests pass; lint, format and tsc clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`ASK_BROWSERSTACK_ALLOW_REMOTE_RELAY` gated the relay on the hosted deployment
while relaying meant ELICITATION — it was a guard against switching on the thing
that pins an McpServer per session, which is what forced sessions, ingress
affinity and a session cap onto that deployment and then OOMed it. Deferred
holds no sessions, so the hazard the guard existed for is the one this branch
deletes. Keeping it meant a manual, forgettable deploy step standing between
users and a feature that is safe by construction.

It was also the weakest switch available. Read at boot, so disabling needed a
pod roll — while `ASK_BROWSERSTACK_DISABLED`, defined ten lines away, is read
PER CALL for exactly that reason, and Atlas's own `delegation.permission_relay`
turns the relay off for every client at once from a config change. Two better
kill switches, neither of which this duplicated.

`remote_mode` goes with it, because it can no longer happen. Its message told
the reader "this hosted server has no way to put an approval prompt in front of
you… mid-run approval works when the server runs locally over stdio" — advice to
go and run the server locally to get something they now already have.

Tests: the `REMOTE_MCP — the relay is a stdio-only feature` block is removed
whole; it pinned that sentence. The property that replaced it was already
covered — remote mode selecting `deferred`, over request/response, with the
stream never opened — and that test no longer needs the opt-in to reach it. One
assertion there had gone vacuous with the mode's removal (`reason` not being a
value that no longer exists) and now pins what is actually true: `used: true`,
no reason at all.

686 tests, tsc clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`permission_relay.contract: 2` on both paths. Atlas reads an absent or lower
value as a build that cannot complete an approval and refuses to park, rather
than handing back an ask nobody can answer.

DECLARED, not inferred, because the two are identical on the way in: the stdio
path here sends `{"mode": "stream"}` exactly as 1.5.1 does, so there is nothing
for Atlas to tell them apart by. Bump it only when a change leaves an older
client unable to COMPLETE the exchange — not merely unaware of a new field.

Why it is worth a field at all: measured against a converged Atlas, 1.5.1
answers a decision without `product`, takes the 400, logs it to stderr and then
reports `ok: true` for a run that created nothing. With the marker it gets an
honest refusal naming the upgrade instead.

Also removes two things the flag removal left behind and lint caught — an empty
`finally` and a `buildRemoteServer` helper orphaned when the `remote_mode` tests
went. Both failed the BUILD, not the tests, so `dist/` had been silently stale:
the "new" client was running without the contract marker and behaving like an
old one until this was fixed.

686 tests, tsc clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review on #445. Four correctness fixes and the comment cleanups; the hosted
opt-in question is left for a separate decision.

WORKS AGAINST BOTH SERVERS. Answering only after the stream closed assumed the
converged Atlas, which emits its asks as the stream ends. An Atlas that predates
it holds the stream OPEN waiting for the decision, so both sides waited until
the server's own five-minute gate denied an ask nobody had seen — and the user
got a refusal no human made. Each ask is now answered as it arrives, and the
reply says which server this is: a bare 204 carries nothing and the run
continues on the stream, anything else IS the continuation and the stream is
over. Both loops go through one `answerAsk`, so the two paths cannot drift.

That removes the deploy ordering constraint in both directions. With the
contract-2 guard already on the Atlas side, neither half now has to ship first.

A LOST REPLY IS NOT "NOTHING HAPPENED". The decision request carries the whole
continuation, so a timeout spans everything from "it never arrived" to "the
write landed and the answer was lost". Both paths reported `not_reached` —
"NOTHING WAS ASKED AND NOTHING WAS REFUSED" — which is the claim that gets the
same change made twice. There is a distinct `outcome_unknown` for it now, which
says not to retry. The deferred transport was also still bounded at 120s, sized
for a request that returned as soon as the run parked; it gets the whole-run
bound the streaming path has.

`next_step` CAN NOW BE FOLLOWED LITERALLY. It says to call again "with exactly
these params" — product, run_id, perm_id, decision — while `query` was a
required string, so a model doing exactly what it was told got InvalidParams
before the handler ran. `query` is optional in the schema and required by the
handler for a start, which is the only path that has anything for it to say.

ALSO: the three resume parameter descriptions ran 117–167 characters against a
60/120 budget, and every client loads them at connect time; they are 32–49 now,
with what they explained at length left to `next_step`, which arrives with the
values. The tool description no longer claims a client that cannot prompt makes
the run read-only, which stopped being true of the hosted path. An orphaned doc
block describing the removed opt-in is gone, along with four "X IS GONE" notes
and a `null` means REATTACH comment for a type that never allowed null.

686 tests before, 694 after; lint, prettier and tsc clean. The compatibility
test was checked against the previous code first — it times out there, which is
the deadlock it exists to catch.