Follow-up to #490 (the MCP capstone in v0.0.200).

Why

The single biggest UX gap surfaced by the v0.0.200 live-fire smoke. Today, agents watching for new resources have to poll `list_resources` / `read_resource`. For chat-style interactions (forum messages, bot conversations, real-time docs) that's the wrong shape — latency-sensitive and wasteful.

JSS already has the primitive: `/.notifications` WebSocket with the `solid-0.1` protocol. The work is wiring it through MCP, not building a new notification system.

What

A new MCP tool:

```
subscribe — Subscribe to change events on a resource or container subtree.
Returns an SSE-streamed sequence of MCP notifications as resources
change. Subscription is WAC-gated (Read on each emitted resource).
```

Wire path: MCP server, on `tools/call` for `subscribe`, switches the HTTP response into SSE mode (Streamable HTTP transport allows this — return `text/event-stream` instead of `application/json`). Subscribes server-side to the existing notification pipe, filters events by the agent's WAC visibility, emits each as an MCP notification.

```
event: notification
data: {"jsonrpc":"2.0","method":"notifications/resource_changed","params":{"path":"/forum/channels/general/abc.jsonld","kind":"created"}}
```

Scope

• Streamable HTTP SSE response path in `src/mcp/index.js`
• New `subscribe` tool handler that bridges `src/notifications/` to the SSE stream
• Per-event WAC filtering (don't leak resources the agent can't see)
• Cleanup on client disconnect
• Test: subscribe, write a resource via another path, observe the event
• Doc update in `docs/mcp.md`

Estimated ~150-250 lines including tests.

Acceptance

• `subscribe` returns an SSE stream of MCP notifications
• WAC-filtered (anonymous subscriber only sees public changes)
• Survives client reconnect cleanly
• Tested against a known write pattern
• Documented in `docs/mcp.md` with a curl example

Related

• feat: expose JSS as an MCP server (--mcp) — proposed v0.0.200 #490 — parent MCP capstone
• TODO-after — `docs/mcp.md` deferral note for `subscribe` is currently true