**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#253438
Forward-Port-Of: odoo/odoo#246163

Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`:

* **Redundant updates** were performed on `location_dest_id` in the move lines and the package levels (which internally update all related move lines too), even when the location remained unchanged.
* The main loop inside `_check_entire_pack` was **O(N^2)** time relative to the number of move lines due to internal filtering logic.
* **Cache misses** triggered unnecessary SQL queries when retrieving `move_line_ids` from `package levels`, while they are already cached via the pickings and can be grouped by `package_level`.

---

### Benchmark
Benchmark conducted on a customer database with **400k** `stock_move_line` records within **800** `pickings`, testing performance of the action `StockQuant.action_validate` with different sizes of move lines. Each test was run multiple times and shown is the average mean, all with negligible variance.

| Metric | Before | After | Delta |
| :--- | :--- | :--- | :--- |
| **Benchmark (1k lines)** | 10.5s | 2.2s | -80% |
| **Benchmark (5k lines)** | 121s | 8.5s | -93% |
| **Benchmark (50k lines)** | 887s | 56s | -94% |
| **Benchmark (400k lines)** | timeout | 777s | (within time limit) |

**OPW-6045513**