feat(orders): log the client price figures the server discards (MON-08)

Step 2 of the owner's MON-08 ruling. An app order is priced by the server
(steps 1, 3, 4 landed with the wage-formula work), but the client's own
wagePercent, discountPercent and flatRialCharge were being thrown away in
silence — so a stale app build, a promotion that expired between the
product page and checkout, and a deliberately tampered request were
indistinguishable and left no trace anywhere.

They are now logged with both numbers, the same pattern already used for
the body's customerId. The pricing itself is untouched: the server's
figures are what the order is charged, and an operator ordering from the
panel still keeps the numbers they typed.

Also adds the comparison test the ruling asked for, which step 3 never
actually had — the suite only proved a tampered request gets overridden.
The new test places one honest order as a customer and the same order as
an operator and asserts the totals are identical, which is the real
claim: an ordinary customer's total does not move. Two more cover the
logging, including that an honest order logs nothing — so the quiet case
cannot pass merely because the method never ran.

Closes STUB-05 in the docs as well: the reference's six hardcoded staff
numbers have been behind PROFILE_ADMIN_MOBILES / ORDER_ADMIN_MOBILES for
a while, but its status still read "pending".

api: 286/286 tests, 26 suites, typecheck clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/parity/PROGRESS.md

@@ -19,11 +19,11 @@ The "Current state" table below is the parity project's and was last updated 202
 
 | Field | Value |
 |---|---|
-| **Phase** | **Phase 1 — admin parity — COMPLETE, at the gate** |
+| **Phase** | **Phase 2 — apps parity — item #1 done** (Phase 1 closed and committed, `83e5d28`) |
 | **Branch** | `main` (the parity branches were merged; see git log 2026-10-08..10-12) |
-| **Status** | All in-scope sections closed: §2 §4 §5 §6 §7 §8 §9 ✅ · §3 ⏸️ out of scope by D16. **283/283** jest tests, typecheck clean. |
-| **Next step** | **GATE question asked 2026-10-12 — waiting on the owner** before Phase 2 (apps parity). |
-| **Blocked on** | the gate answer. Two additive items await an owner ruling: **PERM-02** and the open rows below. |
+| **Status** | Phase 1: all in-scope sections closed (§2 §4 §5 §6 §7 §8 §9 ✅ · §3 ⏸️ by D16). Phase 2: **item #1 MON-08 ✅**. **286/286** jest tests, typecheck clean. |
+| **Next step** | Phase 2 item #2 — **the 5 screens missing from both apps (D3)**. `02-APPS-MATRIX.md` still to be created. |
+| **Blocked on** | nothing. Two additive items await an owner ruling when convenient: **PERM-02** and the open rows below. |
 | **Last updated** | 2026-10-12 |
 
 ### Phase 1 close-out (2026-10-12)
@@ -195,7 +195,19 @@ Consolidated into `00-INVENTORY.md`. Issues found: `ISSUES.md` (26 entries).
 3. **D13** — the retail storefront is preserved but out of scope; see
    `DECISIONS.md` §D13 and `PROTECTED.md` §H.
 
-## Phase 2 — item #1 (fixed by the MON-08 ruling)
+## Phase 2 — item #1 (MON-08) — ✅ DONE 2026-10-12
+
+All four steps of the ruling are in place; see `ISSUES.md` §"Phase 2 — item #1".
+Steps 1, 3 and 4 had landed with the wage-formula work; **step 2 — logging the
+client figures that get discarded — was added 2026-10-12**, along with the
+comparison test the ruling asked for («تست مقایسه‌ای»), which step 3 had not
+actually had: the suite only covered a tampered request, not an honest one.
+`orders.service.spec.ts` is now 16 tests.
+
+An operator ordering from the panel still keeps the numbers they typed — only an
+app order is re-priced by the server.
+
+The original requirement, for the record:
 
 Before anything else in Phase 2: the server must derive `wagePercent`,
 `discountPercent` and `flatRialCharge` from the DB and **ignore** the client's