Sales: snapshot the list price on the order line (discount foundation)

[mforce]

Part of #719.

What

Add ListUnitPriceMinorUnits to SalesOrderItem, captured from the product's
DefaultPriceMinorUnits at line creation. Discount is then derived as
ListUnitPrice − UnitPrice and is stable forever.

Why this blocks everything else in #719

The line already snapshots ProductTypeSnapshot, EggGradeId, BaseUnitFactor
and UnitPrice (spec §10.5) but not the list price it was sold against, so
today there is no stored fact saying a sale was discounted.

Without the snapshot, "was this discounted?" would be computed live against
today's catalog price: raise a product's price next month and every past sale
retroactively becomes a discount; drop it and real discounts vanish. The order
screen, the history badge and the report would each drift, and they would drift
differently. This is the same rule already written into §10.5 for
BaseUnitFactor — redefining a carton must not reinterpret recorded orders.

Scope

• ListUnitPriceMinorUnits (nullable long) on SalesOrderItem, set in
  SalesOrderItem.Create from the product read that AddOrderItemHandler
  already performs. Nullable on purpose — a product with no default price
  has no list price, and that is a different fact from "sold at list".
• Never re-resolved on SalesOrderItem.Update: editing quantity or price does
  not change what the list price was when the line was written.
• Exposed on the order item API response so the read surfaces can use it.
• One new migration (feat(eggs): make cracked and dirty eggs sellable stock via condition grades (#396) #407). Existing rows stay NULL.
• specs/product/specs.md §10.5 updated to name the fourth snapshot alongside
  the existing three.
• Regenerated docs/schema/ (chore(schema): generate PostgreSQL schema documentation #417) in the same PR.

Decide before writing code

1. Null list price. Does an egg product now require a
   DefaultPriceMinorUnits, or do we keep it optional and render those lines as
   no list price? Either is fine; silently showing them as 0% off is not — that
   is the version that lets a discount hide.
2. Pre-migration orders have no snapshot and must read as unknown, not as
   zero discount, in every consumer. Worth asserting in a test now so a later
   slice cannot regress it into a ?? 0.

Acceptance

• A line added against a priced product stores that product's price at that
  moment.
• Changing the product's default price afterwards does not change any stored
  line's ListUnitPriceMinorUnits. This is the test that matters.
• A line added against a product with no default price stores NULL.
• UpdateItem leaves ListUnitPriceMinorUnits untouched.
• Rows written before the migration read as NULL.

Repo rules

• feat(eggs): make cracked and dirty eggs sellable stock via condition grades (#396) #407 — one new migration; never fold the column into InitialCreate.
• chore(schema): generate PostgreSQL schema documentation #417 — regenerate schema docs in the same PR or CI fails the PR.
• Version++ — any new mutation path bumps SalesOrder.Version, with a
  parallel-race integration test.

[mforce]

Mockup

Sizing from the source. Additive and nullable, so it breaks zero existing tests: SalesOrderItem.Create is internal static with exactly one caller (SalesOrder.cs:58), and TestHarness.SeedSalesOrderAsync goes through the public AddItem. AddOrderItemHandler already loads the Product (var product = await products.GetByIdAsync(...)), so the list price needs no new query. Keep the new domain parameter optional and the 10 AddItem call sites in tests need no edit; AddOrderItemRequest never changes, so k6 and both seeders stay untouched.

Real cost is mechanical, not analytical: the migration .cs is ~25 lines but drags a ~2,130-line generated .Designer.cs, a snapshot delta, and a tools/schema-docs/generate.sh run that boots Postgres and does a full Release build. Docker required. ~8 files, about a day.

Currency trap, new since the issue was written. AddOrderItemHandler refuses on SalesOrder.ProductPriceCurrencyMismatch — but only when command.UnitPriceMinorUnits is null. On the explicit-price path, which is exactly the discount case, that check is deliberately skipped, so product.DefaultPriceMinorUnits can be denominated differently from the line. Snapshotting it blind reintroduces the bug that guard exists to stop. Every other money value here is a three-column OwnsOne; a bare long? is defensible only because the line already carries the order's currency, and that reasoning belongs in the code.

[mforce]

Scope note: the line shows its discount, not just the list price

Per owner direction, #720's UI now includes a Discount column on each added
line, showing that line's amount and percent. The seller sees what the line gave
away as soon as it exists, rather than having to subtract list from unit price.

The boundary with #723 moves accordingly, and it is still a real boundary:

• Sales: snapshot the list price on the order line (discount foundation) #720 makes a discount legible — the List price and Discount columns, plus
  the live hint under the price field while typing.
• Sales: mark discounted lines and show a discount total on the order screen #723 makes it loud — the row tint, the Below-list badge, and the
  order-level Discount total above the existing Total: line, along with the full
  four-state rendering.

This costs #720 almost nothing extra: the discount is List − Unit on a value the
line already holds, computed in the client. No new endpoint, no extra query.

The unchanged rule is the one that matters. A product with no list price renders
No list price, never $0.00 and never 0%, in both the List price and
Discount columns.