## Why

Products are currently sold and priced only in their single base unit (e.g. "Hộp"). Stores that sell items which customers also buy in smaller packaging or piece quantities (e.g. "Vỉ", "Viên") have no way to configure or charge a different, correctly-derived price for those units — cashiers can only ring up the base unit.

Separately, and unrelated technically: sales staff and customers can't see a customer's current reward-point balance on the printed receipt — it has to be looked up separately on the customer statistics page. Showing it directly on the receipt lets the customer see their balance at the counter without having to ask. This is bundled into the same change purely for delivery convenience (folded in from a separate, previously proposal-only change, `show-customer-points-on-receipt`) — it shares no code, data, or design decisions with the multi-unit pricing work above.

## What Changes

- Add a "Giá bán theo đơn vị quy đổi" box to the product create/edit forms, letting an admin add/remove multiple conversion-unit rows per product. Each row picks a unit and a conversion quantity; the derived unit price is shown live (read-only), computed as base price ÷ conversion quantity.
- Wholesale prices (`wholesale_prices`, per customer type) are derived per conversion unit with the same formula — no separate wholesale input per unit.
- One conversion-unit row per product can be flagged as the default selling unit for POS; no flag defaults to the base unit (existing behavior, unchanged for products with no conversion units configured).
- Add a unit dropdown to each POS cart line, populated from the scanned product's configured units (base + conversions), preselecting the default unit.
- Changing the unit on a cart line recalculates that line's unit price and subtotal client-side, using the same customer-type-aware formula.
- **BREAKING**: Order creation/update (`OrderController::store`/`update`) now accepts an optional `unit_id` per cart item and computes price server-side from the selected unit instead of always pricing at the base unit — server remains the sole source of truth for price (client-submitted prices are still ignored).
- `order_product` gains `unit_id` and `conversion_qty` columns, snapshotted at order time so historical orders keep showing the unit/ratio actually sold, even if the product's conversion configuration changes later.
- Add a "Điểm thưởng hiện tại" (current reward points) line to the printed POS receipt header (`pos-print.blade.php`), shown only when the order has a customer attached, displaying that customer's live `points` balance at render time (not a snapshot from order-creation time).

## Capabilities

### New Capabilities
- `product-unit-pricing`: Configuring per-product conversion units with auto-derived pricing (retail and wholesale), and selling by any configured unit from the POS cart with server-side price recomputation and order-line unit snapshotting.
- `pos-receipt-customer-points`: Showing a customer's current reward-point balance on the printed POS receipt, when the order has a customer attached.

### Modified Capabilities
(none — no existing spec's requirements change; this introduces new requirements only)

## Impact

- **DB**: new `product_units` table (`product_id`, `unit_id`, `conversion_qty`, `is_default`); `order_product` gains nullable `unit_id`, `conversion_qty`.
- **Models**: new `ProductUnit` model; `Product` gains `units()` relation and a unit-aware price accessor; `Order`/pivot gains the new columns.
- **Controllers**: `ProductController` (store/update/create/edit — persist and load conversion rows), `PosController::scan` (include unit list in response), `OrderController::store`/`update` (accept `unit_id` per item, compute unit-aware price).
- **Views**: `products-add.blade.php`, `products-edit.blade.php` (new box + JS for dynamic rows and live price calc), `resources/views/vendor/admin/index.blade.php` `#scannerItem` jsrender template (unit dropdown), `PosController` inline cart JS (recompute price/total on unit change), `pos-print.blade.php` (reward-points line — no model/controller change, reads the existing `Customer->points` field).
- **Out of scope**: no stock/inventory deduction changes (system does not track stock deduction today); no per-unit barcode scanning (unit is only switchable after the item is in the cart); no snapshotting of the points value shown on the receipt (always the live balance at print time, consistent with the original proposal for this capability).
- **Implementation gate**: every file listed above sits outside the folders Reversa is scoped to write (`.reversa/`, `_reversa_sdd/`, `_reversa_docs/`, `_reversa_forward/`, `_reversa_bugs/`, `_reversa_refactor/`). `.reversa/reversa-config.json` currently has `allowLegacyEdits: false`, so actual code implementation (not this planning work) is blocked until the project owner sets `allowLegacyEdits: true` (globally or via `allowedPaths` covering these files).