still ``lxml.html.clean`` import is needed because ``lxml.html``  init file don't have clean file. So, it
will be not loaded
For reference :-  https://github.com/lxml/lxml/blob/lxml-4.9/src/lxml/html/__init__.py
```
Traceback (most recent call last):
  File "/tmp/tmpj23nirpw/odoo/19.0/./odoo-bin", line 3, in <module>
    import odoo.cli
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/__init__.py", line 2, in <module>
    from .command import Command, main  # noqa: F401
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/command.py", line 8, in <module>
    import odoo.init  # import first for core setup
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/init.py", line 28, in <module>
    from .tools.gc import gc_set_timing
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/__init__.py", line 11, in <module>
    from .i18n import format_list, py_to_js_locale
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/i18n.py", line 8, in <module>
    from odoo.tools.misc import babel_locale_parse, get_lang
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/misc.py", line 40, in <module>
    from lxml import etree, objectify
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 45, in exec_module
    patch_module(module.__name__)
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 67, in patch_module
    module.patch_module()
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/lxml.py", line 14, in patch_module
    lxml.html.clean._find_image_dataurls = re.compile(r'data:image/(.+?);base64,').findall
AttributeError: module 'lxml.html' has no attribute 'clean'
```
https://upgradeci.odoo.com/upgradeci/run/301804


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

Forward-Port-Of: odoo/odoo#266591

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/99ebe9376b [REL] 19.1.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/fde8ddb28f [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405)
https://github.com/odoo/o-spreadsheet/commit/7228270f55 [FIX] range: correctly handle unbounded ranges on row/col changes [Task: 6167358](https://www.odoo.com/odoo/2328/tasks/6167358)
https://github.com/odoo/o-spreadsheet/commit/d21e9b0114 [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894)
https://github.com/odoo/o-spreadsheet/commit/5cf698ee4c [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894)
https://github.com/odoo/o-spreadsheet/commit/f7f8485a4c [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095)
https://github.com/odoo/o-spreadsheet/commit/d51b26de87 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/28c8803429 [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243).

To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically.

However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge.

To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`).

This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16.

Task-5999878

Forward-Port-Of: odoo/enterprise#109379

## Issue
In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the applicants within the pools, and cannot create new pools either.

## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) with demo data
2. Set Marc Demo's *Recruitment* role to *Interviewer*
3. As Marc Demo, navigate to Recruitment > Applications > By Talent Pools
4. **We can see the existing pools, but they all appear empty ("0 Talents"), and we cannot add talents to a pool, nor create new pools.**

## Cause
Interviewer do not see any applicants in the talent pools because of the following rule:

https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/hr_recruitment/security/hr_recruitment_security.xml#L48-L60

In fact, applicants in talent pools do not have a job_id set:

```sql
190=# SELECT a.partner_name, a.job_id FROM hr_applicant a
190-# JOIN hr_applicant_hr_talent_pool_rel tpr
190-# ON (tpr.hr_applicant_id=a.id);

 partner_name  | job_id
---------------+--------
 Cameron Ellis |
 Ethan Carter  |
 Noah Bennett  |
 Test Talent   |
(4 rows)
```

This leads to no applicants being shown to the interviewers in the talent pools.

## Justification
Interviewers by default only have access to applications who they are interviewer for, it is not intended for them to see entire pools of potential candidates. Letting interviewers access the talent pools view is counter-intuitive, as they have nothing they can do from there.

opw-6187187

Forward-Port-Of: odoo/odoo#265812

**Problem:**
When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders white-on-white in the field, and clicking the dropdown shows an empty-looking popup (white options on white system menu).

**Steps to reproduce:**
1. Enable dark mode in user preferences
2. Open Sign > Templates > duplicate any template
3. Add a Selection field with a few options (e.g. Low / Medium / High)
4. Save and Sign Now
5. Reach the Selection field and click it
6. Observe: the dropdown options are invisible (white on white) and, after picking one, the selected value in the field is also invisible

**Cause of the issue:**
The Selection sign item is rendered with a native `<select>` element inside the PDF.js iframe (`sign_items.xml`, `t-if="type == 'selection'"` branch). The iframe's stylesheet (`sign/static/src/css/iframe.css`) declares the `select` rule with `background: transparent` but no explicit `color`, and never styles `<option>` at all. When the OS or the user activates dark mode, the iframe document resolves to a `color-scheme: light dark` root, so the browser's UA stylesheet paints form controls with the dark palette (white text). The popup background stays white (`<option>` has no explicit background), so options render white-on-white. The same UA-white propagates to the displayed value of the `<select>` inside the pink-tinted sign item, which is also nearly white.

**Fix:**
Pinning the `<select>` text color and the `<option>` color/background to fixed light-mode values restores predictable contrast inside the iframe regardless of the surrounding color scheme. We deliberately do not rely on `color-scheme: dark` here — that would only swap which side of the contrast issue we land on (browsers don't reliably honor it for `<option>` background painting), and the sign item background (the pink dashed default style) is itself light, so dark option text on a white popup is the readable target in all themes.

opw-6197638

***Steps to reproduce*:**

- Create and confirm an invoice.
- Open the invoice preview and use the Print option to generate the PDF.
- Send the invoice to the customer.

***Observed behavior*:**

- In the preview, the header is displayed as *Proforma*.
- Before sending the invoice, the downloaded PDF from the Print option does not contain the *Proforma* header.
- After sending the invoice, the preview correctly no longer shows the *Proforma* header, but the Print PDF output also continues without the expected behavior.

***Cause*:**

- The *Proforma* header should be displayed when a confirmed invoice has not yet been sent to the customer.
- Once the invoice is sent, the document should display the normal invoice header instead.
- The PDF generation flow from `action_print_pdf` did not correctly pass the proforma context based on whether the invoice had already been sent.

***Fix*:**

- Update the functional logic in `action_print_pdf` to use: `with_context(proforma_invoice=not self.invoice_pdf_report_id)`
- This ensures that invoices not yet sent to the customer are generated as *Proforma* invoices.
- Once the invoice has been sent, the PDF is generated with the normal invoice header instead.

opw-6169132

Forward-Port-Of: odoo/odoo#265825

**Problem**:
When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers.

**Before this commit:**
If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving.

**After this commit:**
Only SN-002 and SN-003 will be added to the move, which matches the quantity.

**Steps to reproduce:**
1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product.
2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0.
3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking.
4. SN-001 will be added to the move automatically, but the quantity stays at 2.

opw-6121208

Forward-Port-Of: odoo/odoo#266259
Forward-Port-Of: odoo/odoo#263080