Expose and serialize allowAllMcpServerInstructions in TypeScript SDK

从 dist/types.d.ts 和 dist/client.js 开始，然后跟踪生成的 RPC 类型以及 CopilotClient.createSession() 的请求路径，包括 resume 或 update 处理。使用同一个未列入 allowlist 的 MCP server fixture 进行并排测试和线级断言。完成的标准是：省略和 false 会让 canary 保持隐藏，而 true 会将其暴露，并且工具在所有情况下都可用。

Problem

The Copilot runtime protocol supports allowAllMcpServerInstructions, but TypeScript SDK 1.0.11 does not provide a working SessionConfig path for it.

The generated RPC types contain the field, and the runtime describes it as including instructions from every MCP server instead of only allowlisted servers. However:

• dist/types.d.ts does not expose it on SessionConfigBase.
• CopilotClient.createSession() in dist/client.js does not serialize it into the session.create request.
• A consumer adding the property at runtime therefore has no effect.

This prevents evaluation harnesses and other SDK consumers from explicitly testing or enabling instructions from a non-allowlisted MCP server.

Controlled reproduction

A one-turn probe used a temporary MCP server whose unique canary existed only in server-level initialization instructions. The tool description did not contain the canary, and the prompt prohibited tool calls.

• Stock SDK: agent returned NO_MCP_INSTRUCTION_CANARY (18,924 tokens, 1 turn, 0 tool calls).
• Consumer supplied allowAllMcpServerInstructions: true without changing SDK serialization: same negative result.
• Temporary SDK wiring that serialized the field into session.create, together with the consumer option: agent returned the exact instruction canary (19,028 tokens, 1 turn, 0 tool calls).

This isolates the missing SDK forwarding from model variance and MCP tool selection.

Requested behavior

1. Add allowAllMcpServerInstructions?: boolean to the public TypeScript session configuration shared by create/resume paths as appropriate.
2. Serialize it to the runtime request and ensure resumed or updated sessions honor the same policy.
3. Preserve the secure default: omitted or false must continue to exclude instructions from non-allowlisted servers.

Required side-by-side tests

Please cover both policy states using the same non-allowlisted MCP server fixture:

• Disallowed: omitted and explicit false do not expose the server instruction canary.
• Allowed: explicit true exposes the exact canary.
• The server's tools remain available in both states, proving the assertion concerns instruction visibility rather than MCP startup.
• Wire-level tests assert both false and true are serialized correctly where supplied.

The allow/disallow behavior should remain explicit rather than changing the default globally.