Fix #93: pin mlx-swift-lm to last pre-v3 commit + declare swift-transformers

[gsdali]

Closes #93.

Problem

mlx-swift-lm v3 (PR ml-explore/mlx-swift-lm#118 merged 2026-04-01) reshaped its loading API. Notable removals:

• loadTokenizer(configuration:hub:) → moved to AutoTokenizer.from(directory:)
• Hub / defaultHubApi parameter → replaced with a Downloader-based from: parameter
• ModelConfiguration.modelDirectory(hub:) → removed; pass URL directly

LocalLLMClientMLX/Context.swift (lines 39, 61, 69, 97, 102) still uses the v2 API. Consuming this package against mlx-swift-lm branch: "main" fails to compile:

Sources/LocalLLMClientMLX/Context.swift:39:57: error: 'Tokenizer' is ambiguous for type lookup in this context
Sources/LocalLLMClientMLX/Context.swift:61:89: error: cannot infer contextual base in reference to member 'shared'
Sources/LocalLLMClientMLX/Context.swift:69:69: error: 'Tokenizer' is ambiguous for type lookup in this context
Sources/LocalLLMClientMLX/Context.swift:97:20: error: 'Tokenizer' is ambiguous for type lookup in this context
Sources/LocalLLMClientMLX/Context.swift:102:24: error: 'Tokenizer' is ambiguous for type lookup in this context

(The "ambiguous" errors come from both MLXLMCommon and Tokenizers exposing a Tokenizer type once mlx-swift-lm v3 introduces its own.)

Fix

This PR is a minimum-disruption restoration — it does not port Context.swift to the v3 API. Instead it pins to the last pre-v3 commit so today's code compiles cleanly:

1. Pin mlx-swift-lm to commit 2a296f14 (2026-03-27 — last commit before PR #118) via revision:. Reproducible (vs branch:).
2. Declare swift-transformers as a direct dependency at 1.2.0..<1.3.0 (the range pre-v3 mlx-swift-lm pinned). The Tokenizers import in Context.swift was satisfied transitively before, but mlx-swift-lm never re-exported it, so SPM consumers silently relied on the resolution. Making the dependency explicit removes that fragility.
3. Add Tokenizers to LocalLLMClientMLX's target dependencies.

Verification

swift build --target LocalLLMClientMLX   # clean

(Was failing on main before this PR with the errors above.)

Follow-up

A future PR should migrate Context.swift to the mlx-swift-lm v3 API:

• Replace loadTokenizer(configuration:hub:) with AutoTokenizer.from(directory:)
• Replace the hub: parameter with a Downloader (likely HubClient.default from MLXLMHuggingFace)
• Drop calls to the removed ModelConfiguration.modelDirectory(hub:)
• In the same commit:
  • Pinned revision → branch: "main"
  • swift-transformers 1.2.0..<1.3.0 → from: "1.3.0"

Both pin updates are flagged with comments in Package.swift pointing at this migration.

Downstream

OCCTSwiftPartsAgent and any other downstream consumer that hits this issue can now adopt LocalLLMClient via revision: of this PR's branch and unblock their MLX integration paths until the proper migration lands.

[gemini-code-assist]

Code Review

This pull request pins the mlx-swift-lm dependency to a specific revision and adds swift-transformers as an explicit dependency to maintain compatibility with the current codebase following API changes in the MLX backend. A review comment identifies a type mismatch in the version range specification for swift-transformers that would cause a compilation error and provides a suggestion to use the correct versioning syntax.

[gemini-code-assist]

The range literal "1.2.0"..<"1.3.0" is interpreted as a Range<String>, which will cause a compilation error because the package(url:_:) method expects a Range<Version>. To fix this and maintain consistency with the existing dependencies in this file (such as lines 11 and 12), use .upToNextMinor(from: "1.2.0").

Suggested change

	.package(url: "https://github.com/huggingface/swift-transformers.git", "1.2.0"..<"1.3.0"),
	.package(url: "https://github.com/huggingface/swift-transformers.git", .upToNextMinor(from: "1.2.0")),

[tattn]

Thank you for pinning the MLX version!
I will merge this and leave support for the new API as a future task.