MLX: expose topP / topK / minP / repetitionPenalty via CustomGenerati…

[SpiraMira]

…onOptions

The MLX backend hardcoded sampling parameters in toGenerateParameters / toStructuredGenerateParameters (topP: 1.0, repetitionPenalty: nil, topK/minP at defaults) and never read GenerationOptions.sampling, so callers could only tune temperature and maximumResponseTokens. MLXLMCommon.GenerateParameters already supports the full set.

Add topP / topK / minP / repetitionPenalty / repetitionContextSize to MLXLanguageModel.CustomGenerationOptions (all optional, default nil → existing behavior unchanged) and forward them in both parameter mappers, preserving each path's prior defaults via custom?.field ?? <previous default>.

Implements #165.

per @pcuenca looking into bridging issues with (new) FoundationModels

[SpiraMira]

@pcuenca and @james-333i - my attempt at assuaging Pedro’s concerns...

Additional changes

1. Bridge GenerationOptions.sampling into the MLX sampler parameters

The previous change exposed topP/topK/minP/repetitionPenalty on MLXLanguageModel.CustomGenerationOptions, but the MLX backend read those only from that custom block — it ignored the core GenerationOptions.sampling (SamplingMode) that Apple FoundationModels uses. This meant a caller had to express top-p/top-k twice, in two different shapes.

This commit makes GenerationOptions.sampling a unified sampling surface: toGenerateParameters / toStructuredGenerateParameters now also derive MLX params from SamplingMode:

• .greedy → temperature 0 (argmax)
• .random(top: k) → topK
• .random(probabilityThreshold: p) → topP

Precedence is custom block → sampling-derived → existing default, so anything already setting the custom block is unchanged. The SamplingMode seed is not forwarded (MLXLMCommon.GenerateParameters has no per-call seed). Adds unit tests for the derivation and the precedence.

2. OS 27 toolCallingMode support in the Apple FoundationModels adapter

toFoundationModels() now adopts the OS 27 GenerationOptions initializer (which adds toolCallingMode) when built against the Xcode 27 SDK, guarded by #if compiler(>=6.4) + #available(macOS 27/iOS 27/visionOS 27). On older toolchains it falls back to the existing 26 initializer, so the deployment floor stays 26 and it still builds on Xcode 26. (toolCallingMode is passed nil for now — this is the hook for wiring tool-calling later.)

NOTE: I am unable to test the OS 27 support