fix(mlx): resolve tokenizer behavior from model metadata

[RezaGolriz]

Summary

• resolve tokenizer behavior from local config.json, generation_config.json, and tokenizer_config.json instead of repository-name substrings
• derive and deduplicate EOS token IDs from model metadata, including Qwen 3.8 and renamed Gemma/Kimi repositories
• fall back to the fast Kimi tokenizer when the removed slow tokenizer is unavailable
• keep custom tokenizer code opt-in: repository metadata cannot silently enable trust_remote_code

Fixes #1371.
Fixes #2085.

Why this approach

Model names are mutable and user-controlled; architecture and tokenizer metadata describe the artifact that is actually being loaded. The resolver is local-only and fail-closed for malformed existing metadata. This also covers the EOS symptoms in #2265 without adding new model-name allowlists or automatically executing arbitrary repository code.

Validation

• uv run pytest -q src/exo/worker/tests/unittests/test_mlx/test_tokenizer_metadata.py — 8 passed
• uv run pytest -q src/exo/worker/tests/unittests/test_mlx -m 'not slow' — 23 passed, 184 deselected
• uv run basedpyright src/exo/worker/engines/mlx/utils_mlx.py src/exo/worker/tests/unittests/test_mlx/test_tokenizer_metadata.py
• uv run ruff check src/exo/worker/engines/mlx/utils_mlx.py src/exo/worker/tests/unittests/test_mlx/test_tokenizer_metadata.py src/exo/worker/tests/unittests/test_mlx/test_tokenizers.py
• live tokenizer canary against the current moonshotai/Kimi-K2.6 metadata: explicit trust disabled rejects custom code; explicit trust enabled loads, encodes, and decodes successfully with EOS 163586

Safety

No network lookup is added to tokenizer resolution. Invalid local metadata does not reactivate the legacy name heuristics, and remote code remains an explicit model-card/operator decision.