Make the catalog hash honest, share the text helpers, drop the duplicate labels

`catalog_hash` hashed the CSV and the view *names*, so replacing
`sku_l09.jpg` with a different product's packshot left the hash unchanged and
a report could claim the same catalog while every l09 decision in it had
moved. It hashes each view's bytes now.

`identity_lanes` carried its own `normalize_text` and `bigrams`, near-copies
of the ones in `rebuild_catalog` that had already drifted (the lane's table
folded ユ to itself, the catalog's did not). The lane imports the catalog's
now, so one read scores the same either way.

`evidence/image6_v2.json` was byte-identical to `eval/labels/image6.json`; the
evidence scripts and the decision document point at the canonical file and the
copy is gone. `score_crop`'s docstring now states the contract its callers
already depend on: the dict's insertion order is the lane's ranking, and
re-sorting by value names a different SKU than the lane chose.

Tests: the lane is shared by the classify pool, so a concurrent-ranking test
pins that one BFMatcher does not cross crops under eight threads.

recognization/code/engine.py

@@ -566,7 +566,12 @@ class RecognitionEngine:
         return self._lane
 
     def score_crop(self, crop: Any, method: Optional[str] = None) -> Dict[str, float]:
-        """Score one crop, keyed by canonical SKU.
+        """Score one crop, keyed by canonical SKU, in the lane's rank order.
+
+        The insertion order is the ranking and callers rely on it: the local
+        lane's order comes from its rank key while its value is the margin over
+        the runner-up, so re-sorting by value names a different SKU than the
+        lane chose. `list(scores.items())` is therefore the ranked sequence.
 
         Every backend groups by SKU before returning. Scoring each reference
         view separately is what made the demo's default catalog report 22-29 of