Issue:
Swiss payslips count one extra absence day for employees without a working schedule. A one day accident leave can therefore be prorated as two days, reducing the regular wage and overstating the accident salary.

Steps to reproduce:
* Install Swiss Payroll.
* Configure a monthly employee without a working schedule.
* Assign one day of accident time off.
* Generate the payslip for that month.

Cause:
The Swiss wage computation derives absence boundaries from the date portion of the leave's UTC datetimes: https://github.com/odoo/enterprise/blob/16c29e1bab34b5bcb2b001477d928ec5eb294a97/l10n_ch_hr_payroll/models/hr_payslip.py#L313-L330

A fully flexible employee's full day leave starts at local midnight. In timezones ahead of UTC, that start is stored on the previous UTC date, so the inclusive calendar day computation adds an extra day.

Solution:
We need to use the requested time off dates for both payslip range filtering and absence proration. These fields preserve the calendar days selected by the user independently of timezone conversion, while leaving the UTC datetimes and half-day handling unchanged.

opw-6435086

Forward-Port-Of: odoo/enterprise#127849
Forward-Port-Of: odoo/enterprise#127513

**Steps to reproduce**
* Install the `pos_order_tracking_display` module with demo data.
* Open the restaurant POS, preparation display, and status screen in separate tabs.
* From the POS, send an order to the kitchen.
* In the preparation display, mark the order as **Ready**.
* Verify that the order moves to the **Ready** stage on the status screen.
* In the preparation display, mark the order as **Completed**.

**Observation**
* The completed order moves back to the **Almost There** stage on the status 
screen.
* Completed orders should no longer be displayed.

**Cause**
The order stage shown in the preparation display is determined by `_get_pos_orders`. Previously, order lines were retrieved through `_get_open_orderlines_in_display`, which excluded completed orders. 
After the refactor, order lines are fetched using  `get_preparation_display_orders_domain`, which returns completed order lines as well.

Orders are then split into two groups:

* Orders in the **Ready** stage are displayed as **Ready**.
* All other orders are displayed as **Almost There**.

As a result, completed orders incorrectly appear under **Almost There**.

Additionally, `get_preparation_display_orders_domain` contains an incorrect domain introduced by commit https://github.com/odoo/enterprise/commit/8491f7a74363f7de4fd542e0de0b2f06f00f01ae:

* `last_stage_id` is treated as a string literal:
  `('stage_id', '=', 'last_stage_id')`
  which always evaluates to `False`.
* The `todo` condition is also inverted.



**Fix**
This commit fixes two issues:
* Exclude completed order lines from the preparation display.
* Restore the correct domain logic by replacing the faulty condition with the 
simpler equivalent:
```
'|', ('todo', '=', True), ('stage_id', '!=', last_stage_id)
```

This restores the original behavior while keeping the domain easier.

opw-6423519

Currently, an error occurs when a user adds a rental product to the cart, opens the corresponding sales order, removes the rental period, and then opens the cart again.

Steps to replicate:
- Install `website_sale_renting` with demo.
- Open website > shop > add the product named `Projector`.
- Click Ecommerce in the menu bar > Orders .
- Remove the `Confirmed` filter > Click on the top order (should be containing the projector product.)
- Remove the `Rental Period` and go to the cart.

Error:
```
QWebError: Error while rendering the template:
AttributeError: 'bool' object has no attribute 'time'
Template: website_sale.shorter_cart_summary
```

Cause:
- When the user removes the rental period (`rental_start_date` and `rental_end_date`), both fields are set to `False`. When the cart is opened again, these values trigger the error in [line].

- Since the rental period has been removed from the order, the order is converted to a regular Sales Order (see [PR] and its [task]). Therefore, the Rental Period should no longer be displayed.

Solution:
- Use `is_rental_order` to determine whether to render the rental period instead of `has_rentable_lines`, since `has_rentable_lines `only checks whether the product is rentable [1], which is determined by the product's `rental_periodicity` [2].

- `is_rental_order` is a better check here because it indicates whether the rental period is actually defined on the order [3].

[line]: https://github.com/odoo/enterprise/blob/7c80c9ffa9e7812267f2ac285e3a3fc5ca501814/website_sale_renting/views/templates.xml#L207

[task]: https://www.odoo.com/odoo/all-tasks/6003684

[PR]: https://github.com/odoo/enterprise/pull/106381/commits/56ec41d81f7536f047a1586a12ea6f6e8414b844

[1]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L140-L143

[2]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order_line.py#L61-L64

[3]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L135-L138

sentry-7663524549

Forward-Port-Of: odoo/enterprise#128084