…controls

These tests reproduce #21739: when the replay-idle gap elapses before the
agent answers session/load, the runtime never adopts the real response's
config options and the adapter keeps model switching disabled.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

When replay idle made a loaded ACP session usable before the agent answered
session/load, the race interrupted the request waiter, so the real response's
config options, modes and model config id were never adopted, and the adapter
kept model switching disabled because it froze the capability at open.

The runtime now keeps the session/load request running (still bounded by
sessionLoadTimeout and scoped to the runtime) and adopts its response once the
provisional session is active, emitting the usual config/mode events. The
response is dropped if the session was superseded, the runtime is stopping, or
a newer selection or config update landed first. The adapter recomputes
supportsModelSwitchInSession on config updates and publishes it with
provider_session.updated, and the session manager forwards the live
providerSession instead of a spread snapshot.

Fixes #21739

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Registry agents fill their model picker from onSessionConfigurationUpdate,
which only ran for raw config/mode notifications and during setup. The
runtime now emits SessionSetupAdopted after adopting a late session/load
response; the adapter swaps in that setup (so legacy `models` count for
model switching) and publishes the configuration once.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

A late session/load adoption now clears the configured selection so the
next turn configures the model and mode against the real options. The
model-switch capability refresh is upgrade-only, and a late session/load
failure or timeout is logged as failed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…ate session/load

The build snapshot recorded by a Plan configureSession against the
provisional replay-idle setup was empty, so turning Plan off after the late
session/load response was adopted restored nothing. Drop the snapshot on
adoption so the next Plan turn records the real mode.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

…from being adopted

The late-response guard only saw mode/config writes once the agent answered
them, so an agent that serves requests in order could have its stale load
response adopted over a pending set_mode/set_config_option/set_model. Count
those writes when they are sent and drop the late response if any were sent
after the provisional start. The opening model-switch capability also keeps
the negotiated value instead of possibly opening lower.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

# Conflicts:
#	apps/server/scripts/acp-mock-agent.ts
#	apps/server/src/orchestration-v2/Adapters/AcpAdapterV2.test.ts
#	packages/provider-acp/src/server/AcpSessionRuntime.ts

# Conflicts:
#	packages/provider-acp/src/server/AcpSessionRuntime.ts
#	packages/provider-acp/src/server/adapter.ts

# Conflicts:
#	apps/server/src/orchestration-v2/ProviderSessionManager.ts
#	packages/provider-acp/src/server/adapter.ts

… already covers

AI-assisted; verified with the tests and tools listed above.

…it from being adopted

A current_mode_update can leave the mode state reference unchanged (no mode
metadata yet, or a mode outside availableModes), so the identity guard let
the stale load response through and it overwrote the newer mode. Count
accepted mode and config notifications alongside session writes.

AI-assisted; verified with the tests and tools listed above.

…ssion open

The runtime now snapshots its change count before applying buffered startup
notifications, so metadata newer than the provisional start drops the late
response. The adapter holds an adoption that lands during openSession and
applies it once the initial configuration is in place, so the real catalog
and the thread's selection are not overwritten by the provisional ones.

AI-assisted; verified with the tests and tools listed above.