Corrupt parakeet-ctc-110m cache passes validation: missing model.mil makes CoreML segfault on every launch

Read ModelCache.validateCompiledModelLayout, ModelHub.loadModelsOnce, and CtcModels.modelsExist to trace how cache completeness is decided; start by checking whether the validator rejects the reported bundle with model.mil and other files missing. Compare cache checks in both paths, then confirm a corrupt cache is rejected and triggers a fresh download before CoreML loads it.

Environment

• FluidAudio 0.17.7 (503b4bd), used by Voz 0.3.1 through CtcModels.downloadAndLoad() for vocabulary boosting
• macOS 27.0 (26A428), Apple Silicon (arm64)
• Cache: ~/Library/Application Support/FluidAudio/Models/parakeet-ctc-110m-coreml/

What happened

After the first download the CTC cache was incomplete. There was no *.partial file and no revision marker:

parakeet-ctc-110m-coreml/
├── AudioEncoder.mlmodelc/
│   ├── analytics/coremldata.bin
│   ├── coremldata.bin
│   ├── metadata.json
│   ├── model.mil                (1060924 bytes, correct)
│   └── weights/weight.bin       (109805537 bytes; HF: 100778304, sha256 does not match)
└── MelSpectrogram.mlmodelc/
    ├── analytics/coremldata.bin
    ├── coremldata.bin
    └── weights/weight.bin       (567712 bytes, correct)
    # model.mil and metadata.json are missing
# vocab.json, config.json and the tokenizer files are missing

From then on the host app crashed on every launch (7 crash reports in a row):

EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0000000000000000
CoreML  (anonymous namespace)::makeProgramWithMemoryLayout(...)
CoreML  -[MLE5ProgramLibraryOnDeviceAOTCompilationImpl createProgramLibraryHandleWithRespecialization:error:]
CoreML  -[MLE5ProgramLibrary prepareAndReturnError:]
CoreML  -[MLE5Engine initWithContainer:configuration:error:]
...
CoreML  +[MLModel modelWithContentsOfURL:configuration:error:]

Just before each crash, the system log shows:

[com.apple.coreml] Failed to parse ML Program. It is likely an invalid or broken model.
[com.apple.coreml] Not adding memory layout to program because the source program is null.

CoreML segfaults here instead of throwing. Since the process dies instead of getting an error, the purge-and-redownload fallback in ModelHub.loadModels never runs.

Why the cache is never repaired (0.17.7)

1. CtcModels.modelsExist returns false because vocab.json is missing, so CtcModels.download runs.
2. download calls ModelHub.loadModels(repo, modelNames: ["MelSpectrogram.mlmodelc"]).
3. In loadModelsOnce, matchesRevision is true: there is no marker, and the revision is main. allModelsExist is also true, because it only checks that the two .mlmodelc directories exist. So nothing is downloaded.
4. ModelCache.validateCompiledModelLayout checks only for the directory and coremldata.bin, so it passes.
5. MLModel(contentsOf:) crashes the process. The next launch repeats steps 1–5.

From reading current main (a31f151), incompleteFiles now also rejects bundles that contain *.partial files (#819). But a bundle with coremldata.bin present, model.mil missing and no .partial file still counts as complete, so I believe this still reproduces there. I did not run main.

Suggested fixes

• Have validateCompiledModelLayout require model.mil and weights/weight.bin for ML Program bundles, or compare every file against the HF tree listing.
• Run the size/content-ID check (hasMatchingContent) when deciding whether the cache is valid, not only during download. This would also catch the oversized weight.bin.
• Write the revision marker, or a separate "download complete" sentinel, only after every file has been verified. Treat a cache without it as incomplete.
• Use one completeness check for both CtcModels.modelsExist and ModelHub, so they cannot disagree the way they did here.

Workaround

Delete parakeet-ctc-110m-coreml/. On the next launch the models download again, complete and correct, and the app starts normally.

Notes

• I don't know how the oversized AudioEncoder weight.bin came about. The first launch, which ran the download, was probably interrupted, so a resume/append problem in FileDownloader is possible, but I have not confirmed it.
• The SIGSEGV on a broken ML Program is arguably also a CoreML bug that Apple should fix. Either way, FluidAudio cannot catch it, so the cache check needs to catch the broken bundle before it reaches CoreML.

Downstream report: https://github.com/Joelheile/voz/issues/89