OTLP channel: `otlp/export*` server→client notifications aren't surfaced by the clients

Summary

The ahp-otlp:// channel and its generated payload types exist, but the client libraries intentionally drop these notifications instead of surfacing them — so a subscriber has no typed (or even untyped) callback to receive host-exported telemetry. The clients note this is consistent across languages, so this is a cross-client enhancement; the Swift generated types are the concrete example.

What exists today

• Protocol: otlp/exportLogs, otlp/exportMetrics, otlp/exportTraces on the ahp-otlp:// channel, all @direction Server → Client; each payload carries an OTLP/JSON ExportXxxServiceRequest.
• Swift (module AgentHostProtocol): OtlpExportLogsParams, OtlpExportMetricsParams, and OtlpExportTracesParams are generated.

The gap

• These methods are neither in AHPCommands / AHPClientNotifications nor surfaced as SubscriptionEvents. The reference TypeScript client makes this explicit — in its notification switch, otlp/exportLogs falls into the default branch with the comment that such notifications "are not surfaced as SubscriptionEvents to mirror the Rust/Swift clients." (clients/typescript/src/client/client.ts)
• Result: a client that subscribes to ahp-otlp://… receives nothing typed; the generated OtlpExport* types have no reachable decode/route path, so a consumer would have to parse raw JSON-RPC frames itself.

Proposed enhancement

Surface the otlp/export* notifications to subscribers — e.g. as typed SubscriptionEvent cases (or a dedicated OTLP stream) decoded into the generated OtlpExport* params — so a subscriber to the OTLP channel can actually receive host telemetry through the client API.

Version

Observed at protocol version 0.5.2 (latest release) and current main.

Start with types/channels-otlp/notifications.ts to confirm the server-to-client notification payloads, then inspect clients/typescript/src/client/client.ts and the generated Swift OtlpExport* types. Trace how notifications become SubscriptionEvents in each client and identify the corresponding cross-client routing points. Done means subscribers can receive the three OTLP export notifications through the client APIs using the generated payload types.