### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.

### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.

### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account

To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.

### Before
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td style="{color: red}">Stock input</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

### After
(Or normal behavior without inter-company transfer)
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td>Stock output</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

opw-5993147

Forward-Port-Of: odoo/odoo#255439

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/odoo#257258

Backport of https://github.com/odoo/odoo/pull/251769

Before this commit, Discuss code may crash with the following error:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

This happens because delete operations in JS models could lead to inconsistent state of record lists. Deletion of a record is done internally as follow:

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what might happen with deletion of any item in record list. For example, let's have `menuThreads` that have this value:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list methods to avoid accidental triggering of lazy re-compute and re-sort. The accidental re-compute and re-sort come from invoking non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

Task-4793779

Forward-Port-Of: odoo/odoo#260109

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/121f764b18 [REL] 18.2.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/186b0ad444 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/a7c386b34f [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/1a5767b36e [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2d7f723354 [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/0941ca6e76 [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659)
https://github.com/odoo/o-spreadsheet/commit/c40c6d9c0b [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/f434c4122b [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/419b08e869 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/31398d501c [REF] *: apply eslint to entire codebase [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/68a0b8908b [IMP] config: Fix eslint to work alongside typescript [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/5fae2be5bf [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495)
https://github.com/odoo/o-spreadsheet/commit/596e84b8e4 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913)
https://github.com/odoo/o-spreadsheet/commit/556d292f54 [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239)
https://github.com/odoo/o-spreadsheet/commit/a8182bc107 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101)
https://github.com/odoo/o-spreadsheet/commit/799aa03136 [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/91f39f3862 [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/enterprise#112837