feat(match): reverse matching — designs a facility can produce

[touchthesun]

What

The inverse of forward matching (review note #7). POST /api/match finds facilities for a design; this finds designs for a facility — given an OKW facility, return the OKH designs it can produce, ranked by confidence. Useful for a "what can this makerspace build?" view.

Approach

Rather than new matching logic, this composes the existing matcher: for each design in the catalog, run the same per-facility matching against a single-facility pool (the target). A design is reported when it yields a solution at or above min_confidence; results rank by best score. With the current corpus (~27 designs) this is cheap, and results stay consistent with forward matching by construction.

Changes

• Service — MatchingService.find_designs_for_facility(facility, manifests, min_confidence, max_results, explicit_domain). Mirrors find_matches_with_manifest by taking the candidate manifests as an argument, so it's decoupled from storage and unit-testable.
• API — POST /api/match/facility (FacilityMatchRequest: okw_id + min_confidence + max_results + optional domain). Loads the full design catalog and the target facility; returns {designs[{okh_id, okh_title, confidence, rank}], total_designs, designs_considered, facility_name}. 404 on unknown facility.
• CLI — ohm match facility <okw-id> (--min-confidence / --max-results / --domain), table or --json output.
• Docs — reverse-matching example in the API routes reference.
• Tests — service ranking / threshold / max-results / best-score-per-design (unit), plus endpoint wiring (TestClient integration: 404 + response-envelope shape).

Verification

make ready — all gates green (535 passed, parity 4/4, docs ✓).

The frontend "Designs this facility can make" section on the OKW detail page lands separately on frontend-dev.

🤖 Generated with Claude Code