Expose optional message source provenance across SDK languages

## Problem

The runtime already accepts an optional `source` on `session.send`, but the high-level send APIs in the Node/TypeScript, Python, Go, .NET, Java, and Rust SDKs do not expose or forward it. Applications forwarding an agent's message into another session cannot preserve its origin through these APIs.

In Rust, the generated `SendRequest.source` field also exists but is crate-private, so consumers using typed RPC cannot set it through a supported public API.

## Motivating application failure

In the GitHub Copilot app, an orchestrator can receive a child-agent status update that needs no visible acknowledgement. When the recipient completes successfully without assistant text or tool calls, the app can instead show `No response was returned. Send your message again to retry.` and mark the session as needing input. This pressures agents to produce unnecessary replies and encourages resending already accepted messages.

The investigation confirmed successful empty completions being converted into errors when cross-session messages lacked structured sender provenance. It did not establish that every empty completion was intentional. The runtime already permits silent completion for agent-sourced turns; identifying the sender in prompt text is insufficient.

This issue tracks the SDK prerequisite for preserving that provenance. The application must also pass trusted sender source through its delivery paths and handle resulting events correctly. The SDK change alone does not resolve the current app behavior, and it must not suppress genuine human-turn errors or turn source into a general must-reply setting.

## Reproduction

At SDK revision `d5c9d06d8c4118530083848d9c3fa9d615c0a5c4`:

1. Prepare an update originating from another agent.
2. Try to supply `source: "agent-sender-id"` through the high-level send options, or `source="agent-sender-id"` through Python's keyword API.
3. The public option is unavailable; sending through the existing API omits source from the request.

Without provenance, downstream consumers cannot reliably distinguish that agent-originated message from source-less input. Encoding the sender in prompt text is not a substitute for the runtime's source field.

## Expected behavior

Expose an optional source on high-level send and send-and-wait APIs across all six SDKs, preserving it through builders, cloning, and request serialization. Provide a narrow handwritten Rust typed-request builder for callers using `rpc::SendRequest`.

* Forward supplied values unchanged and leave validation to the runtime.
* Omit source when unset, preserving existing behavior.
* Preserve billing, delivery mode, attachments, display prompt, tracing, and request correlation.
* Do not broaden generated-field visibility or add unrelated internal options.

## Semantics and scope

Source identifies the message origin; it is not a requirement for a visible reply. A successful high-level send acknowledgement confirms acceptance and returns a message ID, not proof of recipient consumption. Silence alone should not trigger automatic resending.

This request covers SDK passthrough and documentation, not an end-to-end remote-delivery guarantee or a redesign of runtime scheduling. Remote backends may not preserve source after accepting the request.

## Regression coverage

Cover supplied and omitted source, enqueue and immediate delivery, send-and-wait forwarding, clone preservation where applicable, and unchanged surrounding request fields. Include Rust typed-RPC serialization and local-runtime event propagation.

首先定位六个 SDK 各自的高层 send 和 send-and-wait API，然后跟踪它们的 builder、克隆路径和请求序列化。对于 Rust，检查生成的 rpc::SendRequest 和手写的 typed-request API。当提供的 source 未经修改地被转发、未提供 source 时保留现有请求，并且回归测试覆盖 delivery modes、克隆、序列化和向 local runtime 的传播时，即视为完成。

由索引模型根据 Issue 内容生成。