Currently, a traceback appears when the user opens 'Overview' of a canceled 'Manufacturing Order'.

To reproduce this issue:

1) Install MRP
2) Create a new Manufacturing Order record
3) Give a `product` with a `Quantity` more than the `On hand` quantity of that product 
4) Add a product in the Component with the `To consume` value more than
   the On Hand quantity of that product
5) Click on the `Cancel` button then Click the `Overview` button

Error:-
```
TypeError: can't compare datetime.datetime to datetime.date
```

This error is occurring because of the recent changes from the below.

https://github.com/odoo/odoo/pull/184928/files#diff-a889e57d7462d595b2a3e056dc37237c9ab73d43c42458b52288733ae84aca73L609-R609

Initially, it was `datetime.datetime`, But recently it was changed to the `datetime.date`.
This leads to the above traceback when a comparison is made between 
`datetime.datetime` and `datetime.date` from the below lines

https://github.com/odoo/odoo/blob/cb96e9133590e07880f0e98b21486d578caecd3a/addons/mrp/report/mrp_report_mo_overview.py#L583

sentry-6250719075

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/f5b97e02d [REL] 18.1.6 Task: 0
https://github.com/odoo/o-spreadsheet/commit/54bd8ca5f [FIX] formulas: accept simple values on search range for lookup formulas Task: 4543381
https://github.com/odoo/o-spreadsheet/commit/c89beb7ab [FIX] Rendering: Skip hidden headers Task: 4535794
https://github.com/odoo/o-spreadsheet/commit/135242fb4 [FIX] SheetView: avoid some array allocation
https://github.com/odoo/o-spreadsheet/commit/412d2a654 [FIX] SheetView: remove useless/costy calls to Object.x
https://github.com/odoo/o-spreadsheet/commit/2ed0df61a [FIX] Renderer: Do not draw if no canvas Task: 4535794
https://github.com/odoo/o-spreadsheet/commit/4e8719ba1 [FIX] SheetView: Fix viewports with negative dimensions Task: 4535794
https://github.com/odoo/o-spreadsheet/commit/35e7669af [FIX] Borders: Fix border continuity Task: 4523890
https://github.com/odoo/o-spreadsheet/commit/75e5f6ccc [FIX] renderer: Re-fix box rendering Task: 4526742
https://github.com/odoo/o-spreadsheet/commit/9a35d0d6f [FIX] charts: fix logarithmic dataset trendline Task: 4385057

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: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@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>

\* = web, point_of_sale, pos_self_order

A restricted attachment is an attachment linked to a record the current user cannot access, or linked to no record at all. The `check_access` methods allows access to such attachments, but the `check` and `_search` override methods forbid it.

By verifying `check_access` first (and if it passes never checking `access_token`), users might end up being blocked later in the flow even though they had a valid token.

Ideally `check_access` should be properly implemented for attachment, but it is out of the scope of this fix.

The fix is rather simple, call `_can_return_content` (which for attachment checks `access_token` and calls `check`) before `check_access`. The order is rather arbitrary. `_can_return_content` used to be slower and therefore called only when necessary, but it is no longer slow so it can be called first.

The opportunity is taken to clean the `pos` overrides:
- better check field name first before fetching the record
- use sudo when checking if access is allowed (otherwise it would raise for non-accessible records rather than returning False)

Follow-up of https://github.com/odoo/odoo/pull/186003 (which broke the access) and https://github.com/odoo/odoo/pull/193407 (which fixed performance and allowed to inverse the call order of the checks).

Main:
Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on the Move Line. However, depending on the state of the Move Line, lot_id may not be set and the tracking number will rather be available in lot_name. Currently, we only rely on lot_id, which may lead to an empty tracking number list, which in turn raises an unhandled exception.

 - We should try getting the tracking number from lot_name when lot_id is not set;
 - We should handle the case where the tracking number list is empty.

N.B. : Only an empty tracking number list is problematic, the case of a list populated with null value is already handled by the epc_encoder.

Before:
 - We only get the tracking number from lot_id.name;
 - No verification is done on the tracking number list.

After:
 - Default to lot_name when lot_id is not set.
 - When the tracking number list is empty, set an error warning as the electronic_product_code on the concerned move lines.

Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'.

Steps to produce:
- Change the default company country to other than US.
- Try to install `l10n_us_hr_payroll`.
- Observe the error.
```
ParseError:  while parsing /home/odoo/src/enterprise/saas-18.1/ l10n_us_hr_payroll/data/hr_salary_rule_data.xml:39 
Rule category and structure should belong to the same country

View error context:
'-no context-'
```
The error occurs due to the validation rule in `hr.salary.rule` - [1]. Here, `rule.category_id.country_id`and `rule.country_id` must be the same. However, In the data record [2], `l10n_us_hr_payroll.hr_payroll_gross_pay` does not define the `country_id` [3].

According to [4], when `country_id` is not set, it defaults to the user's company country. If the user's company is not based in the US, this leads to a validation failure in `hr.salary.rule`, resulting in a `ParseError` while loading `hr_salary_rule_data.xml`.

This commit resolves the issue by setting `country_id=base.us` in the category definition [3]. It will prevent conflicts when the user's company has a different default country.

[1] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule.py#L239-L240
[2] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L39-L47
[3] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_category_data.xml#L22-L26
[4] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule_category.py#L20

sentry-6250322704