Steps to reproduce:
- In a fresh 18.0 database (not runbot), install `website_sale_loyalty`
- Website > Configuration > enable "Prevent Sale of Zero Priced Product"
- Set up a "Buy X Get Y" loyalty program to reward a free product (the 3 Large Cabinet one from demo data will work)
- Go to website and add one of the product to cart
- Go the the shop page and increase the quantity one at a time

Issue:
The first additional product over the threshold works fine, but adding one more after that will disable the checkout button and give error message "Warning! Some products in your cart are not available for purchase in your country. Please remove them or contact us."

Cause:
When the reward line is first added, it has the default `price_unit` of the product and 100% discount. On subsequent changes, `price_unit` is reset to `0.00` and gets caught by this check introduced in #284959.

The unit_price of the reward order line is changed to 0 in `_reset_loyalty()@sale_loyalty/models/sale_order_line.py` and is needed for other logic to successfully complete.

Fix:
Another exception is added to `_get_zero_priced_lines()` so order lines from reward products are exempt from the check, using `is_reward_line`

opw-6528237




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
- A coupon program with a coupon assigned to a customer
- In the PoS, set that customer on the order
- Enter the coupon code, its reward line is added
- Remove the reward line
- Click the customer button

Issue:
The customer list does not open. The PoS crashes with "TypeError: Cannot read properties of undefined (reading 'id')" raised while rendering PartnerLine.

Cause:
`partnerId2CouponIds` maps a partner to the ids of its `loyalty.card` records. It is filled at boot and on every `loyalty.card` create, but nothing ever removes an id from it: the models only trigger a create event. Removing the reward line of a code activated coupon deletes that card from the local models (`_setValue` in the order summary), so its id stays in the map while the record is gone. `getLoyaltyCards` pushed `models["loyalty.card"].get(id)` unconditionally, hence an `undefined` entry in the list the PartnerLine template iterates over with `t-key="_loyaltyCard.id"`.

Fix:
Skip the ids whose record no longer exists. The partner keeps its remaining cards, and the path where no card was deleted is unchanged. The stale id is not pruned from the map: it is reached through the reactive store proxy, and mutating it there would notify subscribers in the middle of a render.

opw-6517564

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
- Create a gift card program (several programs sharing the same gift card product show the same issue)
- In the PoS, sell a physical gift card: click the gift card product and set a code through "Sell physical gift card?"
- Click the gift card product again to sell a second physical card of the same value
- Validate the order

Issue:
The second unit is merged into the already coded orderline (one line, qty 2, one code), so the "Sell physical gift card?" link is no longer displayed and the second code cannot be entered. Validating the order then fails with "The operation cannot be completed: A coupon/loyalty card must have a unique code." and the order stays unsynced: the qty 2 line is split into two point entries both carrying the same gift_code, so two loyalty.card records are created with the same code.

Cause:
_setupGiftCardOptions() (and setupEWalletOptions()) pass merge=false so that a gift card line is never merged, and until 17.0 add_product() honored it ("options.merge !== false"). The 18.0 store refactoring dropped it: addLineToOrder() decides merging from a local variable that is only set to false when a price_unit is given in vals, and never reads opts.merge. The option became dead code, in point_of_sale's addLineToOrder as well as for the pos_discount caller.

Fix:
Honor opts.merge === false in addLineToOrder(). Callers that do not pass the option are unaffected, so the default merging behaviour is byte-for-byte the same; only the callers explicitly forbidding a merge (gift card, ewallet and discount lines) get their pre-18.0 behaviour back.

opw-6466324

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Issue:
----------------------------------------
Arabic text in a rigth-to-left text area is not aligned in the downloaded PDF documents.

Steps to reproduce:
----------------------------------------
- Create a template with a rigth-to-left textarea., Make it fillable by the user.
- Click "Sign Now"
- Enter multiline arabic text
- Validate and download PDF
- The lines aren't aligned in the PDF

Cause:
----------------------------------------
We compute the empty space before the line with `stringWidth()` on the line but this method doesn't do text-shaping on arabic text. We then do the text-shaping using `reshape_text()` and draw the line. the text shpaing "merged" some caracters making `stringWidth()` return a higher number than the actual drawned line.

Solution:
----------------------------------------
Call `reshape_text()` before `stringWidth()`.


Before:
<img width="937" height="247" alt="image" src="https://github.com/user-attachments/assets/8a43a677-fd29-4d8e-a1cd-419b358667b9" />


After:
<img width="896" height="213" alt="image" src="https://github.com/user-attachments/assets/cf8d0ebe-e363-4e07-9eb5-e4963e5ca137" />


opw-6438643x

Issue:
Currency rate for payment is recomputed up to 6 digit. However, it may differ from the official one stored in db up to 4 digits. Which creates differencies between invoice and payment rate made at the same date.

Steps to reproduce:
- In MX company,
- Enable USD,
- Set currency rate for today to 1 USD = 17.4455 MXN
- Create a PPD invoice (due date > 40 days) in USD
- Add a line with
	- qty: 1,
	- unit_price: 3.488
	- tax: 16% (default tax)
- Send it to CFDI
- Create payment
- On the invoice Form click on "Update Payment"

Current behavior:
- In the CFDI sheet, Payment and Invoice XML files will have different currency rates

Expected behavior:
- In the CFDI sheet, Payment and Invoice XML files will have the same currency rate

Cause:
PACs require having the payment `amount` to be equal to `currency_amount * currency_rate`. For huge amout it may happen that using the 6 digits rounding of currency rate to compute the amount won't fall exactly on the two digit precision for the amount and payment would be refused. Therefore, for all payment, we recompute a 6 digits precision `currency_rate` from `amount` and `currency_amount` then using it to compute the final amount. However, Banxico (Mexican central Bank) publish rates with a 4 digit precision. Recomputing the currency rate up to 6 digits may slightly change it from the 4 digit precision official currency rate.

opw-6411530

**Steps to reproduce:**
- Install the l10n_sa_edi module, set the company to Saudi Arabia, and onboard the sales journal.
- Set the 15% sales tax to Included in Price.
- Create a customer invoice for an individual with three lines: 19.00, 12.00, and -31.00, all using the 15% tax.
- The invoice totals are -0.01 untaxed, 0.01 tax, and 0.00 total.
- Generate the ZATCA UBL.

**Observed behavior:**
- ZATCA rejects the submission with BR-S-08, BR-CO-13, and BR-CO-15.

**Cause:**
- When the tax is Included in Price, rounding can result in a negative untaxed amount (-0.01) while the tax amount remains positive (0.01). Negative invoice amounts are not accepted by the ZATCA/Fatoora portal, resulting in an invalid UBL and rejection.

**Fix:**
- Add a validation before confirming the invoice to prevent invoices with a negative untaxed or tax amount from being confirmed when ZATCA is enabled. This prevents invalid invoices from being submitted to ZATCA and avoids the resulting UBL validation errors.

Reference: [ZATCA Guidance on Negative Values in Unit Price](https://zatca1.discourse.group/t/negative-values-in-unit-price-and-line/5376negative-values-in-unit-price-and-line)

opw-6433617