deepagents-acp: ACP session/new cwd is ignored — workspaceRoot only ever comes from the server process

**Package:** `deepagents-acp` v0.1.15

## What happens

The ACP `session/new` request carries a `cwd` for the session, but `handleNewSession(params, conn)` never reads `params.cwd`. The workspace root is fixed at server construction:

```js
this.workspaceRoot = options.workspaceRoot ?? process.cwd();
```

so the only ways a client can control the workspace are the `-w/--workspace` flag or the process spawn cwd. A client that (per the ACP contract) sends the target directory in `session/new` gets a session silently rooted somewhere else — every filesystem tool and shell exec then operates on the wrong tree.

## Where it bites

Any host that spawns one server and opens sessions for different directories, or spawns the server from a location that isn't the target project (service managers, sandboxed placements). We (driving it from [prismalens](https://github.com/prismalens/prismalens) over stdio) only noticed because we happened to *also* set the child process cwd — the protocol field alone does nothing.

## Suggested fix

In `handleNewSession`, honor `params.cwd` when present (per-session workspaceRoot, falling back to the server-level default). Sessions already carry per-session state (`sessionId`, `threadId`, mode), so a per-session root fits the existing shape; `createAgent`/`createBackend` would take the session's root instead of the server-global one.

Related: #653 (backend containment — the two together determine what a session can actually touch).

Start at handleNewSession(params, conn) in the deepagents-acp package and trace how createAgent and createBackend receive the workspace root. Verify that session/new params.cwd becomes the per-session root, while sessions without it retain the server-level default; confirm filesystem tools and shell execution use that root.

Written by the indexing model from the issue text.