When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.

Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.

e.g. l10n_es_edi_facturae:633:

```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```

Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.

Introduced in: https://github.com/odoo/enterprise/pull/75327.

opw-6378954

Forward-Port-Of: odoo/enterprise#124691

Steps to reproduce:
===================
1. Create a subscription product, allow one-time sale, sale price 5
2. Add a recurring price 10/month
3. On the pricelist, add an advanced rule: -10% for the monthly plan
4. Open the shop page and look at the product tile

Cause:
=======
On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`.

In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price

With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price.

Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan.
=> Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9).

Solution:
=========
The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`.

opw-6307398

Forward-Port-Of: odoo/enterprise#120872

### Issue before this commit:
When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference.

### Steps to reproduce the issue:
1. Download Accounting and l10n_lu
2. Switch to LU company
3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701)
4. A pop up will appear saying: Click  to create the taxes for this country. so click there to create the taxes
5. Go to Invoices and create a new invoice and be sure that:
	1. be sure the customer has a VAT number in their profile
	2. in tab Other Info the Fiscal Position is set to Belgium
	3. the tax applied is 0% EU S (BE)
	4. date of invoice is in June
6. Open the tax return in 1 July
7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines
8. Click on Validate
9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company

### Cause of the issue:
The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports.

### Reason to introduce the fix:
To ensure tax compliance by appling the correct VAT number from the foreign fiscal position.

opw-6170447

Forward-Port-Of: odoo/enterprise#125210
Forward-Port-Of: odoo/enterprise#124698

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

Forward-Port-Of: odoo/enterprise#120783