### Current behavior:
When a Studio custom One2many field has an invalid relation field (inverse) name, accessing `registry.field_inverses` raises KeyError. On 19.0 this also crashes error-page rendering, leaving the server unusable after closing Studio. On 18.0, it doesn't crash the server.

### Expected behavior:
An invalid inverse name must not crash the registry or error handler; the server should stay responsive so the user can fix the field.

### Steps to reproduce:
1. Install sales, project with demo data
2. Create a sale order, use Studio to add a new "Lines" field (e.g. test line)
3. In the sale order, add a product that has Create on Order field (e.g. plumbing services from the demo data) > Confirm
4. Click on the smart button to go to project/task
5. Switch to Studio again, add a related field in the task, point that to Sales Order > test line
6. Activate debug mode, click on More for test line (task)
7. In properties, turn off Read only. Important here: add an invalid key for Relation Field (e.g. 'hehe')
8. Error popup shows key error. Try to close and exit out of Studio mode > Server crashes with 500 Internal Server Error

### Cause of the issue:
- When a custom One2many field has an invalid `inverse_name` (set via Studio developer mode), `One2many.setup_inverses` accessed `registry[comodel]._fields[inverse_name]` without checking existence
- Building the cached `registry.field_inverses` property then raises an uncaught KeyError and bricks the server with 500 Internal Server Error

### Fix:
- When a custom One2many field has an invalid inverse_name (set via Studio developer mode One2many.setup_inverses accessed registry[comodel]._fields[inverse_name] without checking existence
- Building the cached registry.field_inverse property then raises an uncaught KeyError and bricks the server with 500 Internal Server Error

opw-6479178

Forward-Port-Of: odoo/odoo#287589

… leaves

# **Steps to Reproduce**

1. Create a fresh Odoo 19 database with Time Off, Employees, Payroll, and Planning installed.
2. Create an employee with a Flexible Working Schedule.
3. Go to **Time Off → Configuration → Time Off Types** and create:
   * Name: Test Hourly Time Off
   * Request Unit: Hours
4. Go to **Time Off → Configuration → Public Holidays** and create:
   * Name: Test Public Holiday
   * Date: 14 August 2026
   * Time Type: Test Hourly Time Off
5. Create an employee Time Off using Test Hourly Time Off, covering the public holiday:
   * 27 July 2026 → 30 August 2026
   * Approve the Time Off.
6. Go to Planning → Schedule by Role.
7. Create a new planning shift for this employee.
  
# **Issue**

During the Planning Gantt computation, *`_get_flexible_resource_valid_work_intervals()`* calls *`_format_leave()`*. When the employee's Time Off includes the Public Holiday, multiple `resource.calendar.leaves` records are merged into the same interval. *`_format_leave()`* expects a single record, resulting in an **Expected singleton** error in `hr_holidays/models/resource.py`.

# **Solution**

```python
leave_record = leave[2].filtered('holiday_id')
```

This ensures that only the employee's actual `hr.leave` record is selected when a public holiday is included in the same interval. As a result, `date_from` and `date_to` are accessed on the correct single record, preventing the `Expected singleton` error while keeping the standard public holiday processing unchanged.

[Runbot v19.0 video](https://drive.google.com/file/d/1qg2VqtoxhBV3dIjxW05oQXaxKU-S9cv6/view?usp=sharing)

opw- 6478752

Forward-Port-Of: odoo/odoo#284204

Steps to reproduce
1. In Inventory Settings, enable Lots & Serial Numbers and Expiration Dates.
2. Create a storable product tracked by lot with Expiration Date enabled.
3. Create and confirm a dropship of it, then open the move's Detailed Operations.
4. The pre-filled line works: typing a batch and an expiration date creates exactly that lot at validation.
5. To split the quantity, click "Add a line": it opens the "Pick From" popup, and choosing "Create" there creates the lot and attaches it to the line.
6. On that line, edit "Lot/Serial Number" and "Expiration Date", then Validate.

-> Expected: the values entered on the line are used.
-> Actual: they are ignored; the lot created through "Pick From" is delivered with its own expiration date, the name and date typed on the line have no effect.

Issue
---
On a create-lots-only non-incoming operation like `Dropship`, `show_quant` is derived from `picking_code` alone, so the "Pick From" quant picker is shown even though the operation only
creates lots. Adding a line goes through "Pick From", which creates the lot and attaches its `lot_id` to the move line; from then on the line's `lot_name` and `expiration_date` stay
editable but do nothing, since a set `lot_id` is used as-is at validation and the `expiration_date` is recomputed from the lot, so anything typed there is silently dropped. Such an
operation has no existing stock to pick from, so `show_quant` is now gated on the lot settings too: "Pick From" is hidden and the line's `lot_name` and `expiration_date` become the only
inputs, created into the lot at validation like receipts already do.
https://github.com/odoo/odoo/blob/68dcb950df83d70ff2aea0e05c96cc9b57c1a8a9/addons/stock/models/stock_move.py#L646-L647

opw-6530563

Forward-Port-Of: odoo/odoo#290071
Forward-Port-Of: odoo/odoo#287474