[Domain] Renaming a SKU seeds a fresh zero-stock row and strands the old one

[vedanshujain]

Renaming a product's SKU seeds a fresh zero-stock inventory row for the new SKU and leaves the
old row orphaned, still holding the stock. The merchant's on-hand count silently drops to zero and
the old row is unreachable from the admin UI.

This is pre-existing — upsertProductCommerce has always behaved this way, and the
create-if-absent seedOnHand is doing exactly what it says. PR 1a does not introduce it, but it
does make it marginally more reachable: the admin console becomes the only SKU writer, and the
edit path now seeds too.

Not fixed in 1a on purpose: a correct fix is a rename operation on the inventory row (or a
policy decision that SKUs are immutable once stocked), which is its own change with its own
contract cases, not a rider on the seeding invariant.

Source: plans/one-home-per-field.md §3.5, §9.7.

[vedanshujain]

A second trigger for the same stranding, found while reviewing #164 ("one home per field", PR 1b). Flagging it here rather than opening a new issue, but note that this issue's title names only the SKU-rename path — whoever picks it up should treat the following as in scope.

Trigger: a CMS product is deleted and re-created. The re-created document gets a new content id (em-dash generates a ULID per entry; the id is never reused), so the CMS sync mints a fresh product_commerce row against the new id. The old id's row is left behind — and unlike the SKU-rename case it is not merely an orphaned inventory row:

• content:afterDelete soft-deletes it if the hook fired. If the delete happened while the service was unreachable, or through a path that fires no hook (a direct DB delete, a restore-from-backup, an import), the old row stays deleted_at = NULL and active = true.
• An active, priced row with no CMS document behind it stays visible in Pricing & inventory (the admin list reads product_commerce, not the CMS) and counts toward the low-stock report, so a merchant sees a product they cannot open in the CMS and cannot explain.
• It is not purchasable — the storefront joins from CMS content, and there is no content for that id — so this is an admin-surface and reporting problem, not an oversell one.
• If the re-created product reuses the same SKU, the old row also holds the live-SKU partial index entry, so the new row's first upsert 409s SKU_TAKEN until the old one is soft-deleted.

Why it belongs with the rename case: both leave a product_commerce row whose key no longer corresponds to anything live, and both want the same fix — a reconcile/sweep that can identify rows with no live counterpart, plus a decision about whether the domain should ever adopt rather than orphan. Fixing only the rename path leaves this one open.

Not introduced by #164. PR 1b makes it marginally more visible, because every CMS product now gets a row (so there is a row to strand even for a product that was never priced), but the mechanism predates it. Deliberately out of scope there.