[Bug]: ACP session/delete is never sent to v1-shaped agents that advertise sessionCapabilities.delete (Kiro CLI) #26927

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Not sure (packages/effect-acp, used by packages/provider-acp and packages/provider-acp-registry)

Steps to reproduce

Using T3's own AcpSessionRuntime against Kiro CLI 2.35.1 (kiro-cli acp --agent-engine=v3), which advertises sessionCapabilities.delete:

// condensed from a script that imports the checkout's TypeScript with Node 26
const context = yield* Layer.build(
  AcpSessionRuntime.layer({
    spawn: { command: "kiro-cli", args: ["acp", "--agent-engine=v3"], cwd, env: process.env },
    cwd,
    clientInfo: { name: "repro", version: "0.0.0" },
  }),
);
const runtime = yield* Effect.service(AcpSessionRuntime.AcpSessionRuntime).pipe(Effect.provide(context));
const started = yield* runtime.start();                       // initialize + session/new
const viaApi = yield* Effect.result(runtime.deleteSession(started.sessionId));
const viaRaw = yield* Effect.result(runtime.request("session/delete", { sessionId: started.sessionId }));

Log the ACP wire traffic (a small stdio tee in front of kiro-cli) to see what is actually sent.

Expected behavior

runtime.deleteSession(sessionId) sends session/delete to an agent that advertises sessionCapabilities.delete, like closeSession does, and the session is deleted.

Actual behavior

runtime.deleteSession fails locally and nothing is sent:

runtime.deleteSession (T3 API): Failure {"tag":"AcpRequestError","code":-32601,"message":"Method not found: session/delete"}

The only T3->AGENT requests on the wire are initialize, session/new, and the later raw session/delete. That raw request, sent through runtime.request, succeeds (Kiro answers {}) and removes the session.

Cause:

• packages/effect-acp/src/client.ts:1184-1187: deleteSession returns methodNotFound(session/delete) when negotiatedProtocolGeneration === 1. closeSession right above it is not gated.
• The generation is 2 only when the initialize response has an info field (isV2InitializeResponse, lines 705-709 and 1084-1089). Kiro answers with the v1 shape (agentInfo), so it is treated as generation 1, even though its response advertises "sessionCapabilities":{"list":{},"close":{},"delete":{},...}.
• The v1 schema in this repo defines the capability and the result: packages/effect-acp/src/_generated/schema-v1.gen.ts:142, :2465, :7485.
• The gate came in with feat(orchestrator): introduce new orchestrator #2829 (de34391). I found no test covering deleteSession.

Where it matters: canDelete is derived from the advertised capability (packages/provider-acp-registry/src/server/probe.ts:271 and :626), and session deletion (deleteAcpRegistrySession, probe.ts:646-649, used from driver.ts:815) goes through runtime.deleteSession. So these agents are shown as deletable, but the call fails. I traced this in code and did not click through the UI. The fix suggested in #25382 (delete the probe's session via runtime.deleteSession) would hit the same gate for such agents.

Impact

Minor bug or occasional failure

Version or commit

main @ 4432fbe (apps/server 0.1.4)

Environment

Linux (WSL2), Node 26.10.0, Kiro CLI 2.35.1 run as kiro-cli acp --agent-engine=v3

Logs or stack traces

session sess_<id>; ...
runtime.deleteSession (T3 API): Failure {"tag":"AcpRequestError","code":-32601,"message":"Method not found: session/delete"}
session/delete (raw runtime.request): Success

T3->AGENT REQUEST initialize id=1073741824
T3->AGENT REQUEST session/new id=1073741825
T3->AGENT REQUEST session/delete id=1        # the raw request only; deleteSession sent nothing
AGENT->T3 RESPONSE id=1 {}

Workaround

None found for the UI path. A raw session/delete request deletes the session.

Suggested direction

Send session/delete whenever the agent advertises sessionCapabilities.delete, as closeSession already does. If some generation-1 agents misbehave, the gate could instead use the advertised capability, or canDelete could be reported as false for them, so the UI doesn't offer a delete that always fails.