Description of the issue/feature this PR addresses:

In Peru, foreign currency operations are converted to PEN with the exchange rate of the date on which the IGV obligation arises (article 5, numeral 17 of the IGV Law Regulation). SUNAT considers that a credit or debit note only changes the amount of the operation it modifies, not the date on which that obligation arose, so the note has to be converted with the exchange rate of the modified document (Oficio N.° 024-2000-K00000 on a credit note, Informe N.° 118-2016-SUNAT/5D0000 on a debit note subject to the SPOT system). The SIRE proposals apply the same rule (RVIE: note 3 of Annex 2 of RS N.° 112-2021/SUNAT, as amended by RS N.° 000138-2023/SUNAT; RCE: notes 1 and 4 of Annex 8 of RS N.° 040-2022/SUNAT).

Legal basis (official SUNAT sources):
- IGV Law Regulation, article 5, numeral 17: https://www.sunat.gob.pe/legislacion/igv/regla/cap4.htm
- Oficio N.° 024-2000-K00000: https://www.sunat.gob.pe/legislacion/oficios/2000/oficios/o0242000.htm
- Informe N.° 118-2016-SUNAT/5D0000: https://www.sunat.gob.pe/legislacion/oficios/2016/informe-oficios/i118-2016.pdf
- RVIE, Annex 2, note 3 (RS N.° 000138-2023/SUNAT): https://www.sunat.gob.pe/legislacion/superin/2023/anexoII-000138-2023.pdf
- RCE, Annex 8, notes 1 and 4 (RS N.° 040-2022/SUNAT, p. 28): https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

Current behavior before PR:

Credit and debit notes currently use the rate of their own invoice date, so:
- their PEN amounts (base and IGV) differ from the ones of the modified invoice;
- an exchange difference entry is created when they are reconciled with the modified invoice;
- the rate reported in the PLE/SIRE files differs from the SUNAT proposal.

Steps to reproduce:
- PE company with USD rates of 4.00 PEN on 2024-01-01 and 5.00 PEN on 2024-02-01
- Post a USD invoice of 1,000.00 dated 2024-01-15
- Add a credit note dated 2024-02-15
- The credit note is converted at 5.00 (5,000.00 PEN) instead of 4.00 (4,000.00 PEN)

Desired behavior after PR is merged:

For PE companies, the rate date of the lines of a credit or debit note linked to the document it modifies is now the invoice date of that document, as done for l10n_cz in d5a772458d4e. When the modified document is itself a note, the links are followed up to the first document, so that a note and its reversal keep the same rate. The link fields are added as dependencies of the line currency rate, so that the rate is recomputed when a note is linked after its creation.

Forward-port is disabled on this PR: 18.0 and later versions are handled by odoo/odoo#288655, because from 18.0 the currency rate is stored on the invoice (`invoice_currency_rate`) and the fix has to be done on `account.move._get_invoice_currency_rate_date` instead, as in 063dba210a39.

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

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Commit: https://github.com/odoo/odoo/commit/68343a56ef0e727c8ac0be4875bedd0fb7460d04 added the possibility of having a negative value for taxable amount in zatca xml to fix this warning:

[202] BR-O-08 : [BR-O-08]-In a VAT
breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject
to VAT' the VAT category taxable amount (BT-116) shall equal the sum of
Invoice line net amounts (BT-131) minus the sum of Document level
allowance amounts (BT-92) plus the sum of Document level charge amounts
(BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not
subject to VAT'.

It was removed by https://github.com/odoo/odoo/commit/46ede829705dd043d60e4928d14a1ccfa71ffe9b but this was not the right approach. This commit reintroduce https://github.com/odoo/odoo/commit/68343a56ef0e727c8ac0be4875bedd0fb7460d04

This commit also fix the error when sending an invoice with a 0% or a sale order with a down payment:
- Create a sale order with a 0%.
- Create a downpayment and process it by zatca
- Process the delivery on the SO and create the final invoice.
- The invoice will be rejected by zata with the error:

BR-KSA-80 If Pre-Paid amount (BT-113) is
provided then the Pre-Paid
amount (BT-113) must equal to
the sum total of the Prepayment
VAT category Taxable Amount
(KSA-31) and Prepayment VAT
Category Tax Amount (KSA-32)

If the line is a downpayment, then we take the absolute value.

opw-5072577


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

A control character written into an html field now corrupts every document that later serializes it, and logs an error for translated fields. In l10n_fr_pdp the flow payload ships "Before�After" where "BeforeAfter" is expected, failing
test_flow_payload_removes_xml_control_characters.

Two upstream libxml2 changes combine to cause it:

- 2.13.0, Improvements: "save: Output U+FFFD replacement characters". The serializer writes a � character reference in place of a character it cannot represent.
- 2.14.0, Major changes: "The HTML tokenizer now conforms fully to HTML5." An HTML5 tokenizer emits C0 control characters into the data stream instead of discarding them (only U+0000 is rewritten), so the parser stopped dropping them.

Neither is visible on its own: up to 2.13.8 the parser still discarded the character long before the serializer could see it. lxml bundles libxml2 2.13.8 in its 5.4.0 wheels and 2.14.x in its 6.0.x ones, and requirements.txt pins lxml==6.0.2 for python_version >= '3.14' (Resolute), which is why only that distro build fails.

From there the character survives html_normalize, which serializes with html.tostring, the HTML serializer writing it through raw. It then reaches html2plaintext, which serializes with etree.tostring and strips tags textually, unescaping only 
, >, <, & and  , so the � reference leaks into the "plain text" as eight ordinary characters. By the time dict_to_xml calls remove_control_characters there is no control character left to remove. Writing such a value also makes html_translate raise on translated html fields (narration is translatable through l10n_gcc_invoice), logging an error on every write.

Drop the characters outside the XML Char production in html_normalize, so they never enter a stored value. This restores the behaviour of libxml2 <= 2.13, where the parser discarded them anyway, and makes the result independent of the installed libxml2. The character class moves next to remove_control_characters in tools/xml_utils, which now compiles it instead of repeating it.

Reference:
- https://github.com/GNOME/libxml2/blob/master/NEWS

runbot-944661