match request fixes

[touchthesun]

Subject: Fix OHM match integration: valid OKH payloads, response parsing, and docs

Summary

Matching failed or looked “broken” mainly because the UI did not speak the same contract as supply-graph-ai’s POST /v1/api/match, and responses were interpreted incorrectly.

Root causes

• Invalid request body: The supply-graph test page sent a hardcoded recipe_id (cooking) instead of a manufacturing OKH input. OHM expects exactly one of okh_id / okh_manifest / okh_url, and rejects extra fields (extra = "forbid"), so requests could 422 or hit the wrong domain.
• Wrong response handling: OHM wraps results in { data: { solutions, … } }. The UI looked for top-level fields like components / related_items, so successful 200 responses appeared empty or useless.
• Problematic fetch usage: Setting Origin (and similar) from the client is invalid/forbidden for browsers and did not help CORS.
• Fragile product page: The supply tree view assumed data.solutions always existed and treated HTTP 200 with an empty solution list like a hard failure.
• Path / ops gaps: The real match path is /v1/api/match (not the mock’s /v1/match). Local setup (Docker OHM on 8001, 127.0.0.1 vs localhost for Azure Functions, blob URLs reachable from OHM) was undocumented.

Fixes

• Added packages/front-end/utils/ohmMatch.ts: build okh_url from listing fname, postOhmMatch, parseOhmMatchBody.
• Updated supply-graph-api.vue and products/[id]/supplyTree.vue to use that helper, strip bad headers, and parse data.solutions safely.
• Added docs/match-endpoint-integration.md and README updates: env vars, Docker vs local OHM, CORS, OKH vs OKW workflow (OKH from client URL; OKWs loaded in OHM), verification steps.
• Added scripts/verify-ohm-match.mjs to assert the same payload/headers as the UI against a running OHM.
• Stopped treating empty solutions on 200 as a transport error on the supply tree page.