Dispatch start_code_task still blocked in 1.49585.0: opening a finished session in the UI re-locks the folder (follow-up to #91745, #92452, #92462)

## Summary

On desktop 1.49585.0 (Linux), Dispatch `start_code_task` is refused again with:

```
Failed to start code session: A Claude Code session (local_4c2ba47d-...) is already active in this directory.
```

The stale-record half of #91745 / #92462 is genuinely fixed in this build: `findActiveSessionByCwd` now skips records that have no live query, and the 200 non-archived records sharing this folder no longer block anything. Thank you for that.

What remains is that a finished session becomes a blocker again the moment it is opened in the app. Selecting it in the Code tab warms it, re-attaches a CLI process, and that idle session then holds the folder against Dispatch. In this case the blocking session had completed its last turn 47 minutes earlier and had already been stopped by the app.

Meanwhile four sessions, two of them app-local, were running concurrently in that same folder without any problem. The exclusivity is enforced only on the Dispatch path, where `exclusiveCwd: true` is still hardcoded.

## What is fixed and what is not

1.46388.2 blocked on any non-archived record (see #92462). 1.49585.0 narrows it:

```js
findActiveSessionByCwd(e,t){
let n=this.startingSessionCwds.get(e);
if(n){for(let e of n.keys())if(e!==t)return e}
for(let n of this.heldSessions())
if(!(n.isArchived || !n.query && !n.startResumeInFlight || n.sessionId===t)
&& (this.normalizeCwdKey(n.originCwd||n.cwd,n.backend.remoteTarget)===e
|| n.originCwd && n.originCwd!==n.cwd && this.normalizeCwdKey(n.cwd,n.backend.remoteTarget)===e))
return n.sessionId
}
```

`query` is present for any warmed session, including an idle one with no pending turn, and warming happens when the user merely selects the session in the UI. The caller is unchanged:

```js
startCodeSession: ... o.startSession({...}, {dispatchParentId:r, dispatchParentOrigin:"local", ..., exclusiveCwd:!0})
```

`exclusiveCwd` is set here and nowhere else. Sessions the user opens from the Code tab do not pass it.

## Environment

- Ubuntu 26.04 LTS (Hyper-V VM, Wayland/GNOME), x86_64
- claude-desktop 1.49585.0 from the Anthropic apt repository, Electron 44, bundled Claude Code 2.1.260
- Previous build on this machine: 1.40609.1, held since 2026-09-06 because of #92462; upgraded 2026-09-09 10:32 local time
- Target folder: a CIFS-mounted directory, not a git repository. Dispatch orchestrator runs locally (`dispatchParentOrigin: local`)

## Timeline (2026-09-09, local time)

```
10:28:30 [Stop hook] Query completed for session local_4c2ba47d-... <- blocker's last turn
10:32:42 apt upgrade: claude-desktop 1.40609.1 -> 1.49585.0
10:35:28 Stopping session local_4c2ba47d-...
10:35:30 Session local_4c2ba47d-... query iterator completed <- no query, not a blocker
10:36:2x app relaunched on the new build
10:43:05 start_code_task SUCCEEDS -> local_09c8d558-... created in the same folder
10:55:56 [CCD] LocalSessions.setFocusedSession: sessionId=local_4c2ba47d-... <- opened in the UI
10:55:56 [CCD] Warming session local_4c2ba47d-...
10:55:56 [CCD] Session local_4c2ba47d-... warmed successfully in 103ms <- CLI process re-attached
11:15:12 [error] [DispatchTools] start_code_task failed for : A Claude Code session (local_4c2ba47d-...) is already active in this directory.
11:18:34 same
11:20:40 same
```

The only event between the success at 10:43 and the first refusal at 11:15 is the UI focus at 10:55. Nothing was sent to `local_4c2ba47d-...`; it has been idle since 10:28.

## Why idling does not release it

`WarmLifecycle` is initialized with `arm=when-hidden`:

```
10:36:22 [info] [WarmLifecycle:session] Initialized (arm=when-hidden)
10:36:22 [info] [WarmLifecycle:preview] Initialized (arm=when-hidden)
```

The 900s and 1800s idle timers only run while the session is hidden, so a session left open on screen keeps its `query` indefinitely and keeps the folder locked. Here the blocker had been idle for 47 minutes at the first refusal and 52 at the last.

## Concurrency in the same folder already works

At the moment of the refusals, four sessions had that folder as cwd, two of them app-local children of the same Dispatch parent:

```
pid 3124359 10:43:05 local_09c8d558-... Dispatch child, started after the upgrade
pid 3132512 10:55:56 local_4c2ba47d-... the "blocker", warmed by UI focus
pid 2471685 Sep 8 21:39 remote-control session
pid 3151418 11:23:09 remote-control session
```

They coexist without conflict, so the refusal is not preventing a real collision. It only prevents Dispatch from adding one more.

## Expected

Either of these would resolve it:

1. Base the check on whether a session is actually busy (a turn in flight), not on whether a CLI process happens to be attached. A warmed but idle session should not hold a folder.
2. Stop hardcoding `exclusiveCwd: true` on the Dispatch path, or make it configurable, so Dispatch matches what the Code tab already allows.

Two smaller points:

- The Dispatch tool set (`session_info`, `list_sessions`, `read_transcript`, `start_task`, `start_code_task`, `send_message`, `set_agent_name`, `list_code_workspaces`, `list_projects`) has no archive or release tool, so the orchestrator cannot clear this state by itself. The error text says "already active" but does not say that closing or archiving the named session is the fix.
- No changelog entry from 1.44121.1 through 1.49585.0 mentions this check, and the Dispatch guide still describes spawning many child tasks with no per-folder limit. The behaviour change in 1.49585.0 (the added `query` condition) is undocumented as well, so there is no way to tell from the release notes which builds carry which half of this.

Start by finding the shown findActiveSessionByCwd and startCodeSession call sites, especially where exclusiveCwd: true is set for Dispatch. Read the WarmLifecycle behavior around warmed/focused sessions and query state. Done means an opened but idle finished session no longer blocks start_code_task, or the documented/error behavior is updated if the lock is intentional.

Vom Indexierungsmodell aus dem Issue-Text verfasst.