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

Root cause:
Webp images are not supported by Outlook, so the editor turns each one into an inline base64 image before the body is saved. A mailing with a few webp images ends up with a body of more than 10 million characters, and each background image is copied a second and a third time for the Outlook fallback. lxml stops reading a document that big and gives back what it read so far, without raising anything.

The body is cut in the middle of one of those base64 images. base64.b64decode then gets a piece of an image and raises, which is the error in the ticket. When the cut lands between two elements instead, there is no error at all and the end of the body is simply gone. On the customer's mailing the body is 16.5 million characters and 6.9 million of them are dropped on save.

Fix:
Put the base64 images aside in _convert_inline_images_to_urls before the body is read, and leave a short placeholder in their place. lxml then only reads the tags, which stays small. The image is given back when the attachment is created, and any placeholder still in the body is put back at the end. This method is the right place because it is the one that reads the body while the images are still inside it.

Steps to reproduce:
1. Install Email Marketing.
2. Go to Email Marketing > Mailings > New.
3. Set a subject, pick a mailing list, then open the Mail Body tab.
4. Pick the Start From Scratch theme.
5. Drag a Cover block and replace its background image with a webp image of about 1 MB.
6. Drag three Text - Image blocks and replace each image with a webp image of about 1 MB.
7. Type four lines of text under the last image.
8. Click Save.

=> Odoo Server Error, binascii.Error: Invalid base64-encoded string: number of data characters cannot be 1 more than a multiple of 4

Ticket [link](https://www.odoo.com/odoo/project.task/6450151)

opw-6450151

**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