[FIX] hr_payroll: fix payslip warning bug

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#109791

Description of the issue/feature this PR addresses:

During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet.

But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine.

Current behavior before PR:

Logs may contain warnings such as:

- Patching res.partner.ref with company_dependent=True
- Patching product.template.sale_ok with company_dependent=True
- Patching product.product.default_code with company_dependent=True

even though there is no actual issue (ok normal behavior)

The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine.

Desired behavior after PR is merged:

Keep the same mechanism, but lower the log level from WARNING to DEBUG.
This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG.
Having the production branches green.



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

Forward-Port-Of: odoo/odoo#258444
Forward-Port-Of: odoo/odoo#258326

Steps to reproduce:
1. Create two expenses for different employees (e.g., Expense A for Employee 1, Expense B for Employee 2).
2. Upload different attachments to each (e.g., 2 files for A, 3 files for B).
3. Select both expenses and use the 'Post' action to open the posting wizard.
4. Click 'Post' in the wizard.
5. Check the generated journal entries (vendor bills).
Result: Both vendor bills contain all 5 attachments (copies of A's files and copies of B's files).

Issue:
In `_prepare_bills_vals`, `self.attachment_ids` is collected before the
`grouped('employee_id')` loop (see: https://github.com/odoo/odoo/blob/6b7fff433335edf7459f7a6eb5c274c0f4d5d1df/addons/hr_expense/models/hr_expense.py#L1572-L1578).
Since `self` refers to the full expense recordset, `self.attachment_ids` returns
the union of all attachments across every expense. This combined list is then
assigned to every bill created inside the loop, causing attachments from one
employee's expenses to leak into another employee's journal entry.

opw-6056590

Forward-Port-Of: odoo/odoo#256031

In German location with Fiskaly setup.
POS users hit an AccessError on read when closing the session from the frontend,
then had to finish closing in the backend with admin (base.group_erp_manager) rights.

Steps to reproduce:
-------------------
* Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly
* Use a user with POS rights only (no Access Rights)
* Open POS, sell, then close the session from the POS UI

> Observation:
A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read).

Why the fix:
------------
The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is
already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials.
Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required;
this change fixes unnecessary reads of protected fields in the tax helper,
not the security model of the credentials themselves.

opw-6074960

**Problem:**
When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF.

**Steps to reproduce:**
1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر )
2. Create an invoice with that product
3. Print the invoice PDF in English
4. Observe the brackets are misplaced in the description column

**Current behavior:**
Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text.

**Expected behavior:**
Parentheses correctly wrap the enclosed Arabic text.

**Cause of the issue:**
Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them.

**Fix:**
Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets.

opw-5884712

Forward-Port-Of: odoo/odoo#257881
Forward-Port-Of: odoo/odoo#251190

Bug reproduction:
    1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
    2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
    3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
    4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.

Bug cause:
    1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
    2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear

Bug solution:
    1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"

Tests:
    1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
    2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)

Last Test Update:
    1 - I noticed that contract date changes was not affecting the warning appearance directly
    2 - Unit test is expanded with contract date change and observing the warning appearance

Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.

task - 6006693

Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758