feat(mcp): background MCP tasks → task_notification

[HeavenllyDemon]

Stacked on #1 — base is mcp-sdk-migration, not main, so this diff shows only the tasks work. #1 must merge first.

A task-capable MCP tool now hands the turn back immediately and reports completion through the same task_notification path that backgrounded bash and detached subagents already use.

Server-directed, by design

Norma adds no opt-in surface and never touches a server-authored schema. client.experimental.tasks.callToolStream decides per call:

// sdk: experimental/tasks/client.js
task: options?.task ?? (clientInternal.isToolTask(params.name) ? {} : undefined)

If a tool wants to run in the background, that's the server's declaration to make. A non-task server takes the synchronous arm and is byte-identical to #1 — which is why every pre-existing MCP test passes unmodified.

callToolTask(name, args)
  ├─ not task-capable → 'result' only                 → unchanged behaviour
  └─ task-capable     → 'taskCreated'                 → register + return "Task started: …"
                        'taskStatus'* → 'result'|'error'
                        → settle → takeForNotification → task_notification → wake

What's here

File	Role
mcp/task-registry.ts (new)	Third sibling of bg-registry and bg-agent-registry. Lifecycle only, never throws, takeForNotification exactly-once.
mcp/client.ts	callToolTask consumes the stream; returns at taskCreated so the turn isn't held open, drains the rest in the background. cancelTask passthrough.
mcp/manager.ts	Owns the registry, fires onTaskSettled, shared renderBlocks.
engine.ts	notifyMcpTaskCompletion — +36 lines, 0 deletions, so every existing bg path is byte-identical.
daemon.ts	One later-assigned closure, the same shape dispatchChildren already uses.
test/agent/mcp/fake-task-server.ts (new)	Task-capable server on the SDK's own server half — no new dependency.

Security: server output lands in durable history

A task result is authored by a third-party MCP server and is persisted into session history that replays into every later turn. It goes through the same sanitisation notifyBgCompletion applies to subagent output, plus one step further: both ends of the tag are escaped, not just the closing one — escaping only </task-notification> still lets a payload emit a bare opening tag that reads as a nested block.

The injection test pins containment, not tag stripping: an MCP server returning markup is legitimate, so the guarantee is that hostile content cannot end the block early or fake a nested one, and stays inert inside <result>. (notifyBgCompletion escapes only the closing tag; the same hardening would suit it, but changing that path is out of scope here.)

Races handled

• Abort: ctx.signal cancels both sides — cancelTask upstream so the server stops working, plus a local cancelled state.
• Abort vs. settle: genuinely concurrent. The registry's first terminal state wins, so a straggling result can't rewrite a cancellation into a completion.
• Exactly-once: both paths call onTaskSettled; takeForNotification is the single-consumer claim, so only one notification is ever appended. Pinned by test.
• Image after its turn: ctx.attachImage belonged to a turn that has ended, so it degrades to a labelled placeholder instead of silently vanishing.

Getting a task to actually happen took three attempts

Recorded in the fixture, because each condition fails differently and one fails silently:

1. tool declares execution: { taskSupport: "required" };
2. server declares the tasks.requests.tools.call capability — without it isToolTask returns false early and the call runs synchronously with no error at all;
3. server is constructed with taskStore in its ProtocolOptions — without it the SDK throws before reaching the handler, surfacing as a misleading Invalid task creation result: task undefined on the client.

Verified sequence: taskCreated → taskStatus(working) → taskStatus(completed) → result. A failing task arrives as the stream's error message, not a result with isError: true — so the error arm settles rather than throws once a task exists.

Verification

	Result
core suite	4007 pass / 1 skip / 1 fail (pre-existing sandbox mktemp, reproduces on pristine 4d981b51)
MCP + notification suites	144 / 0
@norma/protocol / @norma/plugin-sdk	212 / 0, 23 / 0
engine-spawn.test.ts	101 pre-existing pass unmodified (the new setup({ mcp }) option defaults to undefined)
tsc --noEmit	6 errors, all pre-existing in approvals.test.ts, none in agent/mcp
verify:workflow	PASS on the real compiled artifact
Size	JS bundle +4,978 bytes; compiled binary unchanged at 71,404,898 (payload fits existing padding)

Not in scope

• input_required interactive fulfilment — treated as terminal. QuestionBroker is the natural future wiring; Norma consumes no MCP elicitation today.
• Task recovery across daemon restarts — the registry is engine-memory, exactly like bg-agent-registry. listTasks(cursor?) is the SDK primitive a future pass would use, and it's paginated.
• Surfacing MCP tasks in task_get/task_list — those are Norma's to-do list, a different concept that shares the word.