* fix(sales-orders): pin the sales_order_items embed FK and teach the embed guard composite keys
Migration 20260902180000_sales_orders_hardening added a composite
(sales_order_id, company_id) foreign key from sales_order_items to
sales_orders next to the original single-column one. PostgREST then saw
two relationships and answered every `items:sales_order_items(*)` embed
with HTTP 300 / PGRST201, so kundorder list, detail, create and the MCP
list tool all failed on prod and staging with "Oväntat serverfel".
- Hint the three embeds with `!sales_order_items_sales_order_id_fkey`
(route, load service, MCP list tool).
- scripts/checks/ambiguous-embed.mjs only parsed single-column
`FOREIGN KEY (col)`, which is why the ratchet reported 0 for this pair.
It now reads composite column lists (named or default constraint
name) in both CREATE TABLE and ALTER TABLE, derives the same 17
ambiguous pairs prod's pg_constraint reports, and flags all three
shipped sites on main.
- Unit tests for the composite shapes: alongside a single-column key,
replacing one, and inline in CREATE TABLE.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q7xJQL2aZo6iRHxCZNntUq
* fix(checks): drop composite embed edges when DROP COLUMN removes a member column
Postgres drops every foreign key a column takes part in, so the
ambiguous-embed parser must release a composite edge (and its constraint
name) when one of its columns is dropped, not only the single-column key.
Otherwise a later migration would keep a pair armed for a relationship
that no longer exists and reject valid embeds. Regression case added.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q7xJQL2aZo6iRHxCZNntUq
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
