## Problem Code running inside a Planner session can't tell which document the session belongs to. An Atomic extension the Planner loads, for example one that adds notes to the room's document in the background, has to call `read_document` / `update_document` over Chopin's MCP with the document's id or URL. Nothing in the session gives it that id:

- **Tool results.** `read_plan` returns `{ revision, source, blocks, comments, questions }` (`apps/server/src/agent/tools.ts:114-147`). `edit_plan` returns `{ ok, revision, blocks, anchors_pending }` (`tools.ts:319-327`). Neither carries the document id or URL. - **Session identity.** The Planner session id is a fresh `crypto.randomUUID()` (`apps/server/src/harness/session.ts:120`), and the Atomic adapter gives Atomic `SessionManager.inMemory(cwd)` (`apps/server/src/harness/atomic/adapter.ts:596`). Neither maps to the room. - **Environment.** Planner sessions run in-process (`adapter.ts:593-623`), so environment variables are shared by every room. - **Prompts.** The Planner instructions say `read_plan` and the edit tools are fixed to "this room's document" (`apps/server/src/agent/planner.ts:84-88`), but they never name it. The turn prompt doesn't either. - **Working directory.** It identifies the room only when the room has no checkout (`<stateDirectory>/planner/<channelId>`, `apps/server/src/harness/atomic/workspace.ts:31-39,58-60`). A room started with a checkout runs in the checkout, so nothing identifies it.

The room's channel id is already the MCP document id (`apps/server/src/mcp/hosted.ts:78`), so the value exists. It just isn't exposed.

Matching documents by source and revision would be the only workaround. That's a guess, and an extension writing to the wrong document is the worst failure here.

## Proposal Expose the room's document identity to the Planner session in a form an extension can rely on:

1. Add `document: { id, url }` to the `read_plan` and `edit_plan` results, using the same id and canonical URL that MCP `read_document` returns. 2. Optionally also expose it at session start, e.g. as Atomic session metadata or a session-scoped value. That lets an extension know the document before the Planner's first `read_plan`.

Option 1 alone is enough. The Planner instructions already tell it to call `read_plan` before relying on the plan.

## Acceptance criteria - [ ] `read_plan` and `edit_plan` results include `document.id` and `document.url` for the room's own document, matching what MCP `read_document` returns for that document. - [ ] This holds for rooms with and without a checkout. - [ ] No other document's identity is exposed. The tools stay fixed to the room's document. - [ ] Unit coverage for both tool results. `bun test`, `bun run types` and `bun run ci` pass.

Assistant-workflow: inline Assistant-duration: unmeasured converged, estimated 10m Assistant-verification: source trace passed: read the cited files on origin/main 85cb6db8 and confirmed no Planner tool result, session id, environment variable or prompt carries the room's document id