yolo-detection-2026: mps fallback still crash-loops, now with "No module named 'onnxruntime'" (#212 follow-up) #213

Follow-up to #207 and the fix in #210/#212.

#212 added an mps branch to load_optimized() that loads the pre-built ONNX through
_load_onnx_coreml() when framework_ok is false. That removed the
No module named 'ultralytics' crash, but _load_onnx_coreml() starts with
import onnxruntime as ort, so on a machine where onnxruntime is missing the skill now
crash-loops with No module named 'onnxruntime' instead. Reported on 0.2.15 in #207.

The user-facing behaviour is unchanged: three restarts, then exit 1, with a raw
ModuleNotFoundError and nothing the user can act on.

Two skill-side defects:

1. _check_framework() prints "will use PyTorch fallback" on every backend. On mps
   that sentence is false by design — requirements_mps.txt deliberately ships without
   torch and ultralytics. The message should name the actual remedy for the backend it
   ran on, i.e. that onnxruntime is missing and how it gets installed.

2. The mps fallback has no precondition check. Before calling _load_onnx_coreml()
   it should confirm onnxruntime is importable and raise a sentence a user can act on
   when it is not, naming the interpreter in use (sys.executable) and the skill's venv.
   Emitting sys.executable at startup would also let a support thread tell in one line
   whether the skill is running its own venv or the system Python.

Root cause of the underlying install failure is on the app side and is filed as
solderzzc/Aegis-AI#749: installs are recorded as successful without an import check, and
the runtime falls back to the system interpreter when the skill venv is absent.

Filed from the PM session.