feat(interpretation-in-map): judge a customer interpretation within the map (step 5)

Thin adapter — it judges the customer's reading WITHIN the already-built
RegulatoryMap, it does not assess abstract legal questions and it is not RCI.

- Reuses the existing assess_interpretation (no new legal reasoning); the 6
  verdicts (plausible/too_narrow/too_broad/partially_correct/unsupported/uncertain)
  pass through unchanged.
- Restricts affected_regulations/affected_obligations to those present in the map
  (intersection); links to the map's uncertain regulations.
- Touched unsupported domains (wastewater/chemicals/...) are reported as
  future_corpus_domains (future_corpus_needed) — never pseudo-evaluated.
- Customer-readable explanation ("Ihre Interpretation ist wahrscheinlich zu eng. …
  Betroffen in Ihrer Map: CRA.").
- POST /reasoning/interpretation-in-map (renders the map, then interprets).
- 7 tests; 63 green (existing reasoning MVP stays green), mypy clean, LOC ok.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

backend-compliance/compliance/interpretation_map/__init__.py

@@ -0,0 +1,18 @@
+"""Interpretation-in-Map — evaluate a customer interpretation within the map.
+
+Thin adapter over the existing `assess_interpretation`: it judges the customer's
+reading against the regulations/obligations actually present in the product's
+RegulatoryMap, and flags touched unsupported domains as future_corpus_needed
+instead of pseudo-evaluating them. No new legal reasoning, no RCI, no UI.
+"""
+
+from __future__ import annotations
+
+from .adapter import interpret_in_map
+from .schemas import InterpretationInMapRequest, InterpretationInMapResult
+
+__all__ = [
+    "interpret_in_map",
+    "InterpretationInMapRequest",
+    "InterpretationInMapResult",
+]