refactor: make the matcher and detector safe for concurrent clients

The recognition server will classify crops from several clients at once. Two
things blocked that:

- OpenCV Feature2D objects were shared across calls, so parallel
  classify_crop() calls could corrupt each other. Each thread now gets its own
  extractor set; the template cache is untouched.
- score_crop() is extracted from classify_crop() so callers that need every SKU
  score (live track aggregation) do not have to re-derive it from the top-5
  list. classify_crop() output is byte-identical to before (verified against the
  pre-change module on 82 real crops x 4 methods).
- ShelfProductDetector accepts device/imgsz so the server can pin inference.

Dependencies: pin ultralytics to the version that wrote the checkpoint and that
the session tracker targets (8.4.153), add lap so ultralytics never
pip-installs it mid-request, and add websockets for the streaming endpoint.

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

recognization/requirements.txt

@@ -1,6 +1,11 @@
 torch>=2.0.0
 torchvision>=0.15.0
-ultralytics>=8.0.0
+# Exact: tracking.py relies on BYTETracker internals; the trained checkpoint was written by 8.4.152
+ultralytics==8.4.153
+# ByteTrack linear assignment; pinned so ultralytics never pip-installs it at runtime
+lap>=0.5.12
+# uvicorn WebSocket support for /v1/stream
+websockets>=13
 opencv-python>=4.8.0
 numpy>=1.23.0,<2.0.0
 fastapi>=0.100.0