feat: bump mlx-swift-lm for glm_moe_dsa (GLM-5.2) support

[solderzzc]

Bumps the submodule to bfc2462, which brings GLM-5.2 support into SwiftLM. Closes stage 1 of #111.

What lands

• mlx-swift-lm#48 — glm_moe_dsa / deepseek_v3_2 load and run with dense attention. GLM-5.2 turns out to be DeepSeek V3.2 (in mlx-lm its model class is a bare subclass), and V3.2's sparse indexer is inert below index_topk:

  if k.shape[2] <= self.index_topk:
      return None

  GLM-5.2 ships index_topk: 2048, so this is numerically exact for the first 2048 positions and diverges beyond them — dense rather than top-2048 sparse. That is enough to exercise --stream-experts against the 308 GB checkpoint, which is what Support for glm_moe_dsa architecture (GLM-5.2 DeepSeek Sparse Attention) #111 actually asks for. The indexer is stage 2.

• mlx-swift-lm#47 — the all-KV-shared assistant regression tests, which no bump had picked up yet.

#48 also generalises a latent trap in DeepseekV3.sanitize, which dropped model.layers.61 as a string literal. That number is just numHiddenLayers; against GLM-5.2's 78 layers it would have deleted a real layer and kept the actual MTP block.

Verification

Umbrella builds clean against the bump. More usefully, verified past the registry — pointing the binary at a glm_moe_dsa config constructs the model and fails only on the absent weights:

Error: Key model.embed_tokens.weight not found in
       DeepseekV32Model.DeepseekV3ModelInner.Embedding

So the architecture is reachable end to end, not merely registered.

What is not verified

No real weights have been run. The smallest glm_moe_dsa checkpoint is 308 GB, so everything upstream is covered by tiny random-init configs that establish shape, flow and weight handling — not numerics against the reference. The first person to run this on the real model should expect to find things these tests cannot see, and the SSD-streaming path at 308 GB with ~40 B active per token is separately uncharted.

🤖 Generated with Claude Code