### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264759
Forward-Port-Of: odoo/odoo#241827

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#264518
Forward-Port-Of: odoo/odoo#260566

**Steps to Reproduce:**
- Start a new meeting (Host Tab).
- Duplicate the tab or open the same meeting URL in another tab (remote tab).
- In the remote tab, open the call menu (dropdown).
- From the host tab, disconnect/end the call.
- Crashes on Remote Tab.

**Current behavior before PR:**
Before this PR, duplicating a meeting tab could leave the remote tab 
with a stale call action dropdown after the host ended the call. Since 
some action properties and handlers still assumed that selfSession 
and channel were always available, interacting with the dropdown could 
crash with errors.

**Desired behavior after PR is merged:**
After this PR, call action labels/classes defensively tolerate 
missing selfSession or channel references, and stale click handlers 
gracefully no-op when the call disappears mid-interaction. This prevents
remote tab crashes during call teardown while preserving the existing UI 
behavior.

task-[6191740](https://www.odoo.com/odoo/project/1519/tasks/6191740)

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

Forward-Port-Of: odoo/odoo#264989

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

Steps to Reproduce:
---
1. Create a new project.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing the template conversion should properly restore the original project's
documents folder to active state and clean up the template's documents folder,
allowing template conversion again without document folder conflicts.

Fix:
---
- Archive original project's documents folder during template creation to
prevent mixed active/inactive states during copy operations
- Implement callback system to properly unarchive original project's
documents folder during undo

task-4916027

Forward-Port-Of: odoo/odoo#264429
Forward-Port-Of: odoo/odoo#223152

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

Forward-Port-Of: odoo/odoo#264848
Forward-Port-Of: odoo/odoo#262321

Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45

Steps to reproduce:
- Create a new database with only the Purchase module installed
- Enable the "Units of Measure & Packagings" option
- Create a storable product "P1" with the following vendor pricelist:
  - Vendor: Azure Interior (1 pack of 6 for $10)
- Create a purchase order:
  - Vendor: Azure Interior
  - Quantity: 3 packs of 6 of P1
- Confirm the PO
- Click the Receive button (available without the Stock module since v19.1)

Problem:
1:/
Expected behavior: qty_received = 3 (in purchase UoM: packs of 6)
Actual behavior:   qty_received = 18 (product UoM: units)

`product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6.

2:/
The parameter `invalid_targets` was not properly passed to the
translation function in the error message, causing a traceback
when trying to receive a PO in an invalid state.

opw-6080527

Forward-Port-Of: odoo/odoo#261630
Forward-Port-Of: odoo/odoo#260163

**Issue**
While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone.

**Steps to reproduce**
- Set the user timezone to UTC+1
- Create a storable product with:
  - quantity: 10 (created today)
  - unit cost: 5
  - valuation method: AVCO
- Go to Accounting > Review > Inventory > Inventory Valuation
- Select today's date
- Click on "Ending Stock"

-> The total value and quantity in stock are 0 instead of respectively 50 and 10.

**Cause**
When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation:
- 12/04 00:00 (user timezone) -> 11/04 23:00 UTC
- Converted to 23:59 UTC -> 12/04 00:59 in user timezone

As a consequence, most of the quantities created on 12/04 are excluded from the valuation.

This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150

In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153

This inconsistency leads to incorrect quantities and valuation results.

opw-5491743

Forward-Port-Of: odoo/odoo#255230
Forward-Port-Of: odoo/odoo#246163

There is no need to do a query to get a random foreign state. This search can be performed many times during imports.

While the query is generally not reading a lot of data, it is still doing a seq scan because of the ORDER BY, while the query can be avoided completely.

```sql
EXPLAIN ANALYZE
  SELECT "res_country_state"."id"
    FROM "res_country_state"
   WHERE "res_country_state"."code" NOT IN ('IN')
ORDER BY "res_country_state"."code", "res_country_state"."id"
   LIMIT 1;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=84.93..84.94 rows=1 width=8) (actual time=0.450..0.450 rows=1 loops=1)
   ->  Sort  (cost=84.93..90.49 rows=2224 width=8) (actual time=0.449..0.449 rows=1 loops=1)
         Sort Key: code, id
         Sort Method: top-N heapsort  Memory: 25kB
         ->  Seq Scan on res_country_state  (cost=0.00..73.81 rows=2224 width=8) (actual time=0.012..0.281 rows=2223 loops=1)
               Filter: ((code)::text <> 'IN'::text)
               Rows Removed by Filter: 2
 Planning Time: 0.075 ms
 Execution Time: 0.462 ms
```

This can be worse if when the table is not in the buffer.

Forward-Port-Of: odoo/odoo#265007