Expose and serialize allowAllMcpServerInstructions in TypeScript SDK

Start with dist/types.d.ts and dist/client.js, then trace the generated RPC types and the CopilotClient.createSession() request path, including resume or update handling. Use the same non-allowlisted MCP server fixture for side-by-side tests and wire-level assertions. Done means omitted and false keep the canary hidden while true exposes it, with tools available in every case.

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.