Add mlx-lm architecture support for xing4_0 (XingChen-AGI/Xing4.0-29B-A4B) — oQ fails with "sensitivity measurement produced no scores"

Is your feature request related to a problem? Please describe.

oQ quantization of XingChen-AGI/Xing4.0-29B-A4B fails instantly (0:00) at the "Preparing quantization inputs" phase, for every oQ level, with:

oQ4: sensitivity measurement produced no scores. Check the preceding log lines for the root cause
(model load, calibration data, or layer discovery), and either fix it or pass an explicit sensitivity_model_path.

The preceding log lines in ~/.omlx/logs/server.log show the real cause:

2026-09-18 08:02:44,073 - omlx.oq - INFO - oQ4 streaming: 8307 tensors in 41 shards
2026-09-18 08:02:44,092 - omlx.oq - INFO - oQ4: measuring layer sensitivity for streaming path
2026-09-18 08:02:44,095 - omlx.utils.model_loading - WARNING - mtp_enabled=True for
    /Users/.../models/XingChen-AGI/Xing4.0-29B-A4B but model is incompatible
    (model_type='xing4_0', mtp_heads=True); MTP path will be inactive
2026-09-18 08:02:44,096 - omlx.oq - ERROR - Sensitivity measurement: model load failed
    ('PreTrainedConfig' object has no attribute 'max_position_embeddings')
2026-09-18 08:02:44,096 - omlx.admin.oq_manager - ERROR - oQ quantization failed: Xing4.0-29B-A4B -> oQ4: ...
Traceback (most recent call last):
  File ".../omlx/admin/oq_manager.py", line 611, in _run_quantization
  File ".../omlx/oq.py", line 6104, in quantize_oq_streaming
    raise RuntimeError(...)

Also logged during plan preview:

omlx.oq - WARNING - Could not build model sanitizer: Model type xing4_0 not supported.

I reproduced the load directly with the bundled interpreter (oMLX.app/Contents/Resources/Python/cpython-3.11/bin/python3.11) calling omlx.utils.model_loading.lm_load_compat(model_path, lazy=True, trust_remote_code=...):

So there are two distinct problems:

1. The blocker: the bundled mlx-lm (0.31.3) has no xing4_0 architecture, so the model cannot be loaded in MLX at all, sensitivity returns {}, and oQ aborts. This makes it impossible to produce oQ4/oQ6/oQ8 builds of this model.
2. A diagnosability issue: with trust_remote_code=False (the default), the failure surfaces as a confusing tokenizer-level AttributeError about max_position_embeddings, which completely hides the actual reason ("architecture not supported"). The oQ error message then points at calibration data / sensitivity_model_path, neither of which is relevant here.

Describe the solution you'd like

1. Add support for the xing4_0 architecture (an mlx_lm.models.xing4_0 implementation, or an oMLX-side model module + sanitizer), so that oQ sensitivity measurement and quantization can run on XingChen-AGI/Xing4.0-29B-A4B.

   Relevant bits from the model's config.json / modeling_xing4_0.py: it is DeepSeek-V3-like (MLA with q_lora_rank: 768, kv_lora_rank: 512, qk_nope_head_dim: 128, qk_rope_head_dim: 64, v_head_dim: 128, YaRN rope; MoE with n_routed_experts: 64, n_shared_experts: 1, num_experts_per_tok: 4, topk_method: noaux_tc, scoring_func: sigmoid, first_k_dense_replace: 2, 40 layers), plus a new Xing4_0HyperConnection module: the hidden state is expanded into hc_mult: 4 parallel residual streams mixed by a Sinkhorn-normalized matrix (hc_sinkhorn_iters: 20, hc_eps, mhc_h_res_clamp_min/max), applied in every decoder layer. There is also an MTP head (num_nextn_predict_layers: 1). Because of the hyper-connection residual topology, aliasing model_type to deepseek_v3 is not a valid workaround — it would load but produce wrong outputs.

2. Independently of (1): make oQ fail with the actual root cause. Concretely, run the architecture-support check (mlx_lm.utils._get_classes / the sanitizer lookup) before the sensitivity model load, and fail fast with something like Model type 'xing4_0' is not supported by the bundled mlx-lm; oQ quantization requires a supported architecture, instead of the generic "produced no scores" message. As it stands, the suggested remedies (sensitivity_model_path, calibration data) cannot fix an unsupported architecture, and the user is sent chasing the wrong thing.

Describe alternatives you've considered

• Enabling trust remote code for the model: does not help — it only swaps the AttributeError for ValueError: Model type xing4_0 not supported., since mlx-lm builds architectures from mlx_lm.models.* and never executes the repo's modeling_xing4_0.py.
• Passing an explicit sensitivity_model_path: not viable, since any proxy would still have to be loaded through the same unsupported architecture path.
• Forcing the streaming quantization through (e.g. sensitivity_map_override) to skip sensitivity: this could write tensors, but the output would be a checkpoint no MLX runtime can load — a broken model, not a usable quant.
• Remapping model_type to deepseek_v3: rejected, see the hyper-connection note above.

Additional context

• oMLX 0.6.4, build 260830015308-macos26-27
• bundled mlx-lm 0.31.3, transformers 5.12.1 (the model's config.json declares transformers_version: 5.14.1)
• macOS 26.6 (Darwin 25.6.0), Apple Silicon
• Model: XingChen-AGI/Xing4.0-29B-A4B, revision 1212b14c607fc384a4d55363f9209a4b47f1d8ec, BF16, 8307 tensors in 41 shards (~58 GB), downloaded through oMLX's own HF downloader
• Goal: publish oQ4 / oQ6 / oQ8 builds of this model on Hugging Face; currently blocked at the first step.