[FEATURE]: Surface MCP server->client custom notifications to the session (push wake-up)

Summary

opencode's MCP client drops every server->client notification except notifications/message (forwarded to the logger) and notifications/tools/list_changed (triggers a tool re-list). Custom notifications like notifications/termgram/message, plus notifications/progress, are received then silently discarded — there is no path for a push-style MCP server to reach the session, the model, or plugin hooks.

This makes it impossible to build an MCP server that asynchronously wakes the agent (e.g. a Telegram assistant server pushing "new message arrived, reply now"). The only workaround today is client-polling tools (wait/watch loops), which are time-boxed (60–110s) and never fire mid-task.

Current behavior

packages/opencode/src/mcp/index.ts (~line 456):

• client.setNotificationHandler(LoggingMessageNotificationSchema, …) → routes to serverLog() / the opencode logger
• client.setNotificationHandler(ToolListChangedNotificationSchema, …) → re-fetch tool defs, publish ToolsChanged

No other setNotificationHandler is registered, so custom and progress notifications fall through silently.

Expected behavior

1. Custom notifications/* from an MCP server should not be dropped: at minimum they should be observable (plugin hook / session event bus / SSE stream) with their method + params intact.
2. A defined path for a notification to wake the session — forwarded as a steer/synthetic user turn so the current agent model gets it, subject to a per-server opt-in (capability or a session-level setting) so a noisy server cannot spam the model.

Use case

termgram (a personal Telegram MTProto MCP server, grammers-based) already pushes notifications/termgram/message with { chat, id, at, out, from, text, media } on every incoming message via the MCP protocol (verified working with a probe client; Peer::send_notification on rmcp 3.3). The agent never sees it. The goal: someone messages me on Telegram → opencode surfaces it → the assistant replies.

Related issues

• #32010 — promptAsync wake prompts to idle sessions are silently dropped (the existing async-wake primitive is broken; any wake path here likely depends on fixing it)
• #47622 — externally injected (steer) turns not rendered while TUI is attached
• #44788 — plugin event.subscribe delivers zero events; context/synthetic injections never reach the model prompt
• #35443 — feature request: more V2 session APIs for plugins, including session injection

Environment

• opencode (CLI, current stable at time of report), termgram MCP server as local stdio transport, rmcp 3.3, protocol 2025-06-18
• Linux x86_64
• Existing wait tool clamps timeout 1–110s — there is no unbounded wait, so polling cannot substitute for push