feat: auto-detect VLM checkpoints on the CLI, and fix a false positive it exposed

[solderzzc]

Extracted from `fix/pr57-speculative-ci` rather than a rebase (context: #109's resolution). Its `ModelArchitectureProbe.swift` and tests were already shipped verbatim, presumably via #57 itself — only the CLI wiring and its test were still missing.

The gap

`Server.swift` already probed the architecture at load time and then discarded the result for the CLI: `let isVision = self.vision`. Confirmed the user-facing effect directly before touching anything:

```
$ SwiftLM --model LiquidAI/LFM2.5-VL-450M-MLX-4bit # no --vision
[SwiftLM] Loading LLM (large language model)...

subsequent image request fails

```

`InferenceEngine.swift` — SwiftBuddy's own loader — already auto-detects unconditionally. The CLI now mirrors that, keeping `--vision`/`--audio` as explicit overrides:

```swift
let isVision = self.vision || (!self.audio && architecture.supportsVision)
```

Verified all three directions: LFM2.5-VL-450M now loads as VLM and answers an image request with no flag; a plain LLM (Qwen2.5-0.5B) does not false-positive; explicit `--vision` still forces VLM loading.

What wiring this up exposed

The fixtures suite broke. `moe-nested` (#145) started failing with `Key vision_tower.patch_embedder... not found`, because its `model_type: "gemma4"` — chosen for the unrelated reason that `Gemma4Configuration` decodes `text_config` only, giving the MoE-nesting test a real nested shape to exercise — was now read by the newly-active CLI auto-detection and routed to `VLMModelFactory`.

Not a fixture-only bug. `MLXLLM/Gemma4.swift`'s `Gemma4Configuration` (the `LLMModelFactory` `"gemma4"` entry) has no `vision_config` field at all — a real, intentionally-supported text-only checkpoint shape in this codebase's own registry. `ModelArchitectureProbe.knownVisionModelTypes` listed bare `"gemma4"` as vision-triggering regardless of that. This would have broken loading a real text-only Gemma4 checkpoint the moment anything started acting on the probe's result — which is exactly what this PR does. Removed `"gemma4"` from that list; the separate `vision_config != nil` check already distinguishes the two correctly, since only `VLMModelFactory`'s struct requires that field.

Also swapped the fixture's decoy container from `vision_config` to `audio_config` — independently the more honest choice, since a real text-only Gemma4 checkpoint would never carry `vision_config` at all. `audio_config` is excluded from the expert-count walk by `ModelProfiler.nonLanguageContainers` the same way, so the decoy still proves what it proved before.

Regression test

`testVLM_AutoDetectsLFM25WithoutVisionFlag` in `tests/SwiftBuddyTests/VLMTests.swift`, adapted from `fix/pr57-speculative-ci` to match main's already-refactored `captureStartupOutput` helper (main had the refactor; only the second test case was missing).

Red-green verified: fails with `Unsupported model type: lfm2-vl` against the pre-fix `isVision` line, passes once restored.

Verification

check	result
fixtures	6 passed, 0 failed
contract	10 passed, 0 failed, 2 skipped
VLMTests	both cases pass
LFM2.5-VL-450M	auto-detects, answers image request
Qwen2.5-0.5B (plain LLM)	no false positive
explicit `--vision`	still works

Refs #109

🤖 Generated with Claude Code