Elicit primitive schemas reject extra JSON Schema keys (pattern, format, etc.)

Follow-up to #1768 (see https://github.com/modelcontextprotocol/typescript-sdk/pull/1768#issuecomment-4157011552).

#1768 added .catchall(z.unknown()) to the top-level requestedSchema in ElicitRequestFormParamsSchema, so keys like $schema / additionalProperties emitted by z.toJSONSchema() are now accepted. However, the property-level primitive schemas — StringSchemaSchema, NumberSchemaSchema, BooleanSchemaSchema, EnumSchemaSchema (packages/core/src/types/schemas.ts ~L1720-1829) — are still strict objects.

That means a server doing:

const schema = z.object({ name: z.string().regex(/^[a-z]+$/) });
client.elicitInput({ requestedSchema: z.toJSONSchema(schema), ... });

produces properties.name = { type: "string", pattern: "^[a-z]+$" }, and pattern is rejected by StringSchemaSchema. Same for format, exclusiveMinimum/exclusiveMaximum, default, const, etc.

Complication

Simply adding .catchall(z.unknown()) to each variant in PrimitiveSchemaDefinitionSchema risks ambiguous union discrimination, since the variants are distinguished by type. Options:

• Per-variant .passthrough() while keeping type as the discriminator
• Explicitly add only the spec-listed JSON Schema keys to each variant
• Switch the union to z.discriminatedUnion("type", ...) so extra keys don't affect matching

Scope

requestedSchema property-level primitives only. inputSchema / outputSchema already use .catchall() at the top level and don't constrain property shapes, so they're unaffected.

Start in packages/core/src/types/schemas.ts around StringSchemaSchema, NumberSchemaSchema, BooleanSchemaSchema, and EnumSchemaSchema, and compare them with the top-level requestedSchema catchall. Determine how to accept extra JSON Schema keys without breaking type-based union matching. Done means property-level primitive schemas accept keys such as pattern, format, and default while preserving validation of the type field.