[Adapters] Stop sku_owners/customer_emails declaring a unique index that leaks onto sibling collections

[vedanshujain]

Summary

• Add-to-cart failed on the second request for any given SKU with a raw D1 UNIQUE constraint failed error, surfacing to shoppers as a generic "Something went wrong."
• Root cause: sku_owners (and identically customer_emails) declared their natural key as a uniqueIndexes entry, on the belief that "no physical index exists in any tier." On the currently pinned host release that's no longer true — a declared unique index materializes as one physical SQLite index per plugin, keyed (plugin_id, collection, field), with no per-collection scoping. reservation_keys and reservation_index (inventory) also carry a top-level sku field, one row per reserve attempt, many rows legitimately sharing a sku — so those collections collided on sku_owners' declared index the moment a second reserve happened for any SKU: the first add-to-cart for a product worked, every subsequent one threw.
• Fix: both collections now declare their natural key as a plain (non-unique) indexes entry instead. The create-if-absent compare-and-set against the sku/email-as-document-id was always the real enforcement; the unique index was redundant for its own collection and unsafe for its neighbors. Corrected the stale comments claiming no physical index exists.

Test plan

• pnpm lint — clean
• pnpm typecheck — clean
• pnpm vitest run packages/store-emdash — 744 passed, 0 failed (817 skipped, PG-dialect-gated)
• pnpm vitest run packages/plugin/test/commerce-storage.test.ts packages/plugin/test/sandbox — 21 passed, 0 failed
• Root-caused and reproduced locally against the exact production error text before this fix (two independent standalone repros against the host's index-generation code)
• Post-merge: redeploy and verify add-to-cart end-to-end on the live site

🤖 Generated with Claude Code

https://claude.ai/code/session_01HPywdmMJ9B4V1ME6GrxuDu