## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

## [FIX] website_sale_renting_planning: prepare payment if demo is installed

Before this commit, the demo  `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup.

After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared.

https://runbot.odoo.com/odoo/runbot.build.error/940273

## [FIX] website_sale_renting_planning: unforbid weekend in tests
Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday.

This commit fixes that but setting  `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week.

https://runbot.odoo.com/odoo/runbot.build.error/940312

## [FIX] website_sale_renting_planning: search for product in shop page

Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page.

After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page.

https://runbot.odoo.com/odoo/runbot.build.error/940275

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238