Add a CoreML rung on macOS

The macOS ladder was the CPU provider alone, with CoreML listed as a gap.
It is now CoreML, then the CPU, then tract — unmeasured, since nobody here
has a Mac, and safe to ship unmeasured because the probe's clock rejects a
CoreML slower than the CPU and `attempt` refuses one that crashes.

- `Rung::CoreMl`, a compiling rung like TensorRT: an ML Program with every
  compute unit allowed, falling back to the CPU until each model's program
  is built. The embedder stays on the CPU, as on the Hexagon (§7).
- The cache is one directory per model and runtime version. CoreML keys a
  model committed from memory on its input and node names, not its
  weights (ONNX Runtime 1.29, coreml_execution_provider.cc), so two
  exports of one architecture would otherwise share a program.
- The fingerprint on macOS is the chip and the OS release, which ships
  CoreML.
- The desktop looks for the runtime in the bundle's Contents/Frameworks
  and Homebrew's prefixes; fetch-desktop-runtime.sh on a Mac downloads
  ONNX Runtime 1.29.0 for Apple silicon, which carries CoreML.

docs/dev/macos.md says what exists, how to build it, and which log lines
to ask a Mac user for.

apps/darkroom-desktop/src/main.rs

@@ -124,5 +124,21 @@ fn runtime_dirs() -> Vec<PathBuf> {
         PathBuf::from("/usr/lib/darkroom"),
         PathBuf::from("/usr/lib"),
     ]);
+    // An app bundle keeps its libraries in `Contents/Frameworks`, beside
+    // the `Contents/MacOS` the executable is in; then Homebrew's
+    // `onnxruntime`, Apple silicon's prefix before Intel's. Homebrew's build
+    // may lack CoreML, which the probe finds out for itself.
+    #[cfg(target_os = "macos")]
+    {
+        if let Ok(exe) = std::env::current_exe() {
+            if let Some(bin) = exe.parent() {
+                dirs.push(bin.join("../Frameworks"));
+            }
+        }
+        dirs.extend([
+            PathBuf::from("/opt/homebrew/lib"),
+            PathBuf::from("/usr/local/lib"),
+        ]);
+    }
     dirs
 }