Document why Core ML is not shipped

Converts fine (fp16, ~710 MB) but the .pte fails to LOAD with 0x23 in the portable tensor parser. Distinct from the coremltools#2825 dynamic-shape crash, which fails at execute.

coreml/NOTES.md

@@ -0,0 +1,36 @@
+# Core ML is not shipped for this model
+
+The Core ML exporter exists in `export-scripts` and converts successfully, but the
+artifact it produces cannot be loaded, so no `.pte` or `config.json` is published
+here. Use the XNNPACK or MLX build instead.
+
+## Why
+
+Conversion succeeds (fp16, about 710 MB). Loading it in the ExecuTorch runtime
+does not:
+
+```
+[tensor_parser_portable.cpp:192] getTensorDataPtr() failed: 0x23
+[method.cpp:606] Failed parsing tensor at index 0: 0x23
+```
+
+Note what this is **not**. It is not the dynamic-shape crash that disables Core ML
+on the other text models in this project (apple/coremltools#2825). That one fails
+at execute; this fails at **load**, inside the *portable* tensor parser. Ops the
+Core ML partitioner did not claim kept their constants in the ExecuTorch program,
+and that data is unreadable. The artifact size or a constant-segment issue is the
+plausible cause.
+
+Because it never executed, the dynamic-shape question remains **open** for
+LFM2.5-ColBERT-350M. It never got far enough to hit it.
+
+Re-tested on 2026-08-20 with the software-mansion-labs fork toolchain, rebuilt and
+loaded under the fork runtime: identical `0x23`. So this is not an artifact of the
+PyPI wheel, unlike the YOLO fp16 MLX case that the fork did fix.
+
+## Two deliberate differences from the other backends
+
+The Core ML variant loads the model in **float32**, because Core ML has no
+bfloat16 input dtype, and does **not** apply `quantize_model_`, which packs
+weights for the MLX runtime. So the Core ML build is unquantized, and its size is
+not comparable to the MLX one.