fix(purchase): prevent split and concurrent overreceipts

[cb8010d6]

Problem

Receipt validation read order quantities outside the write transaction and checked split rows separately. A 10-unit PO receiving duplicate rows 6+6 could record 12 stock units but only 6 received units; concurrent requests could also overreceive.

Changes

• Fresh company-scoped order/line reads, validation, receipt, per-line progress, stock/cost ledger and status in one Serializable transaction.
• Aggregate quantities by PO line while retaining legitimate separate locations/batches; update each line once.
• Three bounded attempts for rolled-back P2034 or receiptNo collisions only. Postcommit response read remains outside retry; no repeated writes on response failure.
• Canonical four-decimal row/order/stock quantities, accepting only machine representation noise such as 0.3-0.1 while rejecting genuine finer precision and rounded zero.
• No new request idempotency contract: repeated partial calls remain distinct receipts and are bounded by remaining quantity. No historical backfill, new events or accounting policy.

Validation

Astra xhigh implementation and independent Astra review. 67 focused purchase tests passed, API typecheck/lint passed. 13 real PostgreSQL cases added: duplicate overflow, valid split, precision/noise, forced concurrent conflicts, valid concurrent partials, late-write rollback, tenant boundaries and no postcommit retry. Exact head b0a373f8597fd090a53e6c6d00bfd79e3808a6e5 passed all gates in run 36288911041: 851 regular tests (28 scripts, 681 API, 142 Web), 90 real PostgreSQL regressions including all 13 new receipt cases, 13 stocked-trade + 12 manufacturing HTTP steps and 9 actual Chromium cases. Actual logs inspected. Updated base #44 is included by ancestry and content.

Stacked on #44; no production migration/deployment or main merge.