## Issue
When a use rmanually increases the invoiced quantity on a timesheet invoice, subsequent timesheets logged in future periods can no longer be invoiced. The system assumes that the most recent logged hours are already covered by the previously over-invoiced amount, blocking the billing of the most recent timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Invoicing Policy: Based on Timesheets
    - Create on Order: (Project &) Task
3. Create an SO:
    - Customer: Any
    - Product: P (any quantity)
    - Confirm
4. Record hours on the task created:
    - 06/01/2026 (June 1st): 1 hour
    - 07/01/2026 (July 1st): 1 hour
5. Create the invoice for the June timesheet entry (by setting a timesheets period when creating the invoice), then **change the quantity to any value strictly greater than 2** and confirm.
6. Create the invoice for July
7. **An "Invalid Operation" error appears, stating that there's nothing to invoice, even though the timesheet entry from July was never invoiced.**

## Cause
Since https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20, the computation of the quantity to invoice changed to include the difference between the quantity delivered and the quantity already invoiced. In the flow described by the steps to reproduce above, the quantity to invoice is larger than the quantity delivered, making the `qty_to_invoice` equal to `0.0`.

https://github.com/odoo/odoo/blob/626d31fa0191bfe7ca8e1fcf177357eeeb60f2c7/addons/sale_timesheet/models/sale_order.py#L331-L334

The reason for the fix above being the partial refunding of timesheet-related invoices, we can keep that solution when working with refunded invoices, and keep the previous behavior for other cases.

This solution solves the issue in the steps to reproduce above, but was also manually tested on the issues from https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20 and https://github.com/odoo/odoo/commit/64cf4afabd0c5ef040cf87fc6f3125fe0bb81bbb.

opw-6485674

Forward-Port-Of: odoo/odoo#286301
Forward-Port-Of: odoo/odoo#284470

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

Forward-Port-Of: odoo/enterprise#130058
Forward-Port-Of: odoo/enterprise#126661

Example of steps:

- open any form view with a date field
- navigate to this date field with tab
- For example clicking on the previous field and pressing tab
- type another date press enter (without opening the picker)
- save
=> The change has not been saved.

`onInputKeydown` closes the picker on Escape and on Enter the same
way: by calling `saveAndClose()` directly, without first calling
`updateValueFromInputs()` to parse the raw text typed in the input
into the reactive `pickerProps.value`.

This doesn't work when the calendar popover was never opened
(i.e. the value was typed by hand instead of picked visually),
`saveAndClose()` calls `apply()` directly, which only pushes
`pickerProps.value` to `onApply`. Since that value was never refreshed
from the input's text, `apply()` sees no change and silently returns
without calling `onApply`, so the typed value is lost.

Every other confirmation path (`onInputChange`, the popover's `onClose`, and `Ctrl+Enter`) already calls `updateValueFromInputs()` before proceeding, so plain Enter was the only path missing it.

To fix this we call `updateValueFromInputs()` before `saveAndClose()` in the Enter/Escape case, like every other confirmation path already does.

opw-6511435

Forward-Port-Of: odoo/odoo#285963

### Issue:
When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or Employee views

For example, if a plan has:
- Default Applicability: Unavailable
- A line with Domain: Invoice, Company: My Company, Applicability: Mandatory

Opening the analytic distribution on a Work Center shows `Mandatory` instead of the default `Unavailable`

### Cause:
In commit https://github.com/odoo/odoo/commit/ffcf2ee1a3185ef73db93bfd95625844506692c5 `_get_score` was updated to return `0.5` when the applicability line's company matches the caller's company, even when no `business_domain` is provided

In `_get_applicability`, the loop selects the first rule whose score exceeds the current minimum, which starts at `0`:
https://github.com/odoo/odoo/blob/710e056e5171af2ab72d7d7793da3518f12faf5e/addons/analytic/models/analytic_plan.py#L255-L264

A score of `0.5` is enough to win over the default applicability, so a company-only match on a domain-specific rule incorrectly overrides the default when no `business_domain` is passed

### Steps to reproduce:
- Install `mrp` and `accountant` with demo data
- Enable Analytic Accounting in Settings
- Open the Internal analytic plan and edit its applicability line:
  -- Remove the account prefix
  -- Default Applicability: Unavailable
  -- Domain: Invoice, Company: My Company (SF), Applicability: Mandatory
- Go to Manufacturing > Configuration > Work Centers
- Open any work center and click on Analytic Distribution

Before the fix, Internal is shown as Mandatory instead of Unavailable
Removing the company from the applicability line confirms the issue

opw-6404884

Forward-Port-Of: odoo/odoo#280312

Steps to reproduce
1. On a Manufacturing Order, open the Miscellaneous tab, click in Additional Notes, type "/file", pick "File" (Insert a file from Documents), select a document and save.
2. Open the Shop Floor of that Manufacturing Order.
3. On the order card, click the link shown in the note.

Expected: the link opens in a new tab.
Actual: the Notes edition dialog opens and the link is not opened.

Issue
---
On the Shop Floor the Additional Notes HTML field is rendered inside a container whose click handler opens the note edition dialog, its links carry no target and the handler stops the event propagation, so clicking a link opens the edition dialog instead of the linked document. Additional Notes became an HTML field in ebc30649c0f5, which allowed such links while this rendering was never adapted to open them.
https://github.com/odoo/enterprise/blob/bfda5100ddd423f9e5fb91a9f83b4719c1f58397/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L58-L63 The note links now receive target="_blank" after mount and on every patch so they open in a new tab like the readonly HTML field viewer, and the container handler ignores clicks landing on a link so it no longer opens the edition dialog for them. https://github.com/odoo/enterprise/blob/bfda5100ddd423f9e5fb91a9f83b4719c1f58397/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L106-L111

opw-6487702

When the quantity of a make-to-order manufacturing order is changed, its finished move is copied to propagate the extra quantity downstream. In some cases (after splitting then merging back productions) that copy is not merged back, so the order ends up with two finished moves for the same product.

On validation, two things then go wrong:
- _post_inventory writes the produced quantity on each finished move,
  so both get the full quantity and the production is doubled
- mrp_account._cal_price prices the finished move and calls
  ensure_one(), which raises "Expected singleton" for an average/fifo
  product, so "Produce All" fails

Split the produced quantity across the finished moves with unit_factor (like _set_qty_producing already does), and price them as a whole instead of expecting a single finished move.

Steps to reproduce:
- Create a BoM for product A with the MTO route, and a component B
- Create a Sale Order for 30 units of A, confirm it
- Split the MO into 3 productions of 10, merge two of them
- On the third, Update Quantity 10 -> 15, then Produce All
- The product should be produced once (15, not 30), with A valued in
  average/fifo it instead of an error.

opw-6242504
opw-6310972
opw-6307025
opw-6354739

Forward-Port-Of: odoo/odoo#286173
Forward-Port-Of: odoo/odoo#269254

In this PR, https://github.com/odoo/odoo/pull/186250, the `product_uom` field was renamed to `product_uom_id`. However, in the `delivery` module, `product_uom_id` is dropped from the values when the delivery line is created. 
This causes `product_uom_id` to be recomputed.

This commit reintroduces `product_uom_id` in the values to prevent the field from being recomputed.

**Description of the issue/feature this PR addresses:**

For a strange reason, when a module inherits from `sale.order.line` and adds some computed fields with `precompute=True`. `price_unit`, `price_subtotal`, and `price_total` are computed incorrectly.

I have attached a module to demonstrate the issue.

https://github.com/user-attachments/assets/ebdd8695-c9d8-477b-b5cf-ba6d8d41e84a

Without this change, the test fails, and Odoo incorrectly recomputes the fields, as shown in the video.
<img width="1232" height="515" alt="image" src="https://github.com/user-attachments/assets/27370f1f-e7b7-4102-a606-0181b9d1a97a" />

When the ORM computes fields marked as `precompute=True`, in this function `_add_precomputed_values` https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/odoo/orm/models.py#L4836, `price_unit` is 0, but the records get `price_unit` from the product. Therefore, when [_compute_amount](https://github.com/odoo/odoo/blob/0d44f26d9b0fb1c1a5db463cf1f8dd0d3c72ba26/addons/sale/models/sale_order_line.py#L855) is called, the values are computed with an incorrect `price_unit`.
<img width="1087" height="940" alt="image" src="https://github.com/user-attachments/assets/92feadf0-7f93-4acc-8f1a-931db0655fcc" />

**Steps to reproduce the issue:**

- Install the attached module. [sale_precompute.zip](https://github.com/user-attachments/files/31265993/sale_precompute.zip)
- Configure a delivery carrier as free for orders over 1, and set the fixed price to 5, for example.
- Create a sales order and add a product with a value greater than 1.
- Add the shipping method. The price should be 0. In the sales order line, `price_unit` is 0, but `price_subtotal` and `price_total` are equal to 5 (the product's sale price).

For more context, this module is a simple example extracted from the OCA `product_secondary_unit` module, which adds a mixin with these fields: https://github.com/OCA/product-attribute/blob/18.0/product_secondary_unit/models/product_secondary_unit_mixin.py. In the `sale_order_secondary_unit` module, `sale.order.line` inherits from this mixin.

You can see the error in this PR: https://github.com/OCA/sale-workflow/pull/4535.
https://github.com/OCA/sale-workflow/actions/runs/32259842816/job/96090194021?pr=4535#step:8:509

I understand that this requires a deeper investigation into precompute to solve the underlying issue, but I propose setting `product_uom_id` in the `_prepare_delivery_line_vals` method as a temporary solution while the final solution is being investigated.

I understand that this field should not have been removed from `_prepare_delivery_line_vals`; the referenced PR only renamed the field and did not intend to remove the value from this method.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284316
Forward-Port-Of: odoo/odoo#283551

Steps to reproduce:
- Have an external VoIP software configured (e.g. Linphone)
- Have your Odoo configured and opened too
- Call your VoIP number, using your smartphone => Both the softphone and Linphone ring
- Answer or reject using Linphone => The VoIP call record in Odoo immediately switches from "Trying to call" to "Missed".

While there was no guarantee for our VoIP integration to work alongside Linphone in 19.0, we decided this should be an easy safe enough fix. Starting 19.2 (with [1]), the fix will be simplified and hopefully prettier thanks to the ameliorations that were made.

After this fix, provided Odoo is open while Linphone is used, the call records will now switch to the right terminated / rejected status, still immediately once Linphone answers / rejects.

In future versions and especially 20.0+, the system will be different and will allow way more features like this one to work better (e.g. here the call record only even exists if Odoo is opened while using Linphone and we won't have any information about the call duration).

[1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e

task-6449259

Forward-Port-Of: odoo/enterprise#130047
Forward-Port-Of: odoo/enterprise#127077

Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
    - Routes: MTO + Buy
    - Tracking: By Unique Serial Number
    
- Create a Finished product:
    - Route: Manufacture
    - Tracking: By Unique Serial Number
    - BoM:
        - component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All

Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.

`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()` 
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy 
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).

At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()` 
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).

only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.

Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.

opw-6421531

Forward-Port-Of: odoo/odoo#285405
Forward-Port-Of: odoo/odoo#281258

**Steps to reproduce:**
- Install l10n_din5008 and Accounting.
- Enable Snailmail from Accounting → Settings.
- Create a German customer (Fiscal Country: Germany).
- Create and post a customer invoice using the DIN5008 report layout.
- Select Send by Post.
- Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters.
- Open the generated letter and send it.

**Observed behavior:**
The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning.

**Cause:**
The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering.

While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks.

**Fix:**
Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context.

Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout.

**References**

* **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225)
* **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869)

opw-6387869

Forward-Port-Of: odoo/odoo#286056
Forward-Port-Of: odoo/odoo#285891

Issue
-----------
Long delivery method names containing lists of locations/zones do not wrap properly on the eCommerce checkout page, causing the layout to overflow.

Cause of the issue
-----------
The first column of `[.o_delivery_method_row](https://github.com/odoo/odoo/blob/saas-19.3/addons/website_sale/static/src/scss/website_sale_delivery.scss#L2)` uses `minmax(max-content, 1fr)`. `max-content` prevents the column from shrinking when the delivery method name is too long.

Steps to reproduce
-----------
1. Create a Delivery Method with a long list of locations/zones in its name.
2. Go to the eCommerce checkout at the address page.
3. Observe that the delivery method name does not wrap and breaks the layout.

Before Fix
-----------
The `max-content` minimum prevents the delivery method name from wrapping, causing the layout to overflow.

<img width="1781" height="852" alt="image" src="https://github.com/user-attachments/assets/1150a8ef-e2d8-49ab-9553-fe9728258060" />



After Fix
-----------
Change `max-content` to `min-content` so the column can shrink and the delivery method name wraps.

<img width="1882" height="890" alt="image" src="https://github.com/user-attachments/assets/84cfd5a4-796d-4b9f-bfdb-c18434f8b67f" />



[OPW- 6486780 ](https://www.odoo.com/odoo/project/70/tasks/6486780)
[UPG- 4609267 ](https://upgrade.odoo.com/odoo/upgrade.request/4609267)


Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284714

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `stock`, `purchase`, and `accountant`
- Create a storable product with:
  - Tracking Inventory enabled
  - Control Policy set to **Ordered Quantities**
- Create and confirm a Purchase Order with some unit price
- Do not receive or invoice the order
- From the Purchase Order gear menu, click **Accrued Expense Entry**

Issue:
------
The Accrued Expense Entry wizard opens, but no accounting lines are
generated.

For products invoiced on **Ordered Quantities**, the ordered quantity
should already be accrued even though nothing has been received.

Cause:
------
This issue was introduced after this changes [commit](https://github.com/odoo-dev/odoo/commit/81f25bc57b8433a65bf33950c64dc7582240a229)

Previously, the accrual wizard relied on the stored
`qty_to_invoice` field, whose computation already respected the
product's Control Policy.

For products invoiced on **Ordered Quantities**,
`_compute_qty_invoiced()` computes the quantity to invoice from the
ordered quantity:

https://github.com/odoo/odoo/blob/810a02a577c2811dc5c12f0abf45eebb9cf96d00/addons/purchase/models/purchase_order_line.py#L147-L152

The refactoring replaced this logic with the new
`amount_to_invoice_at_date` field, which always computes the invoicable
quantity as:

`qty_received_at_date - qty_invoiced_at_date`
https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/purchase/models/purchase_order_line.py#L282-L285

This formula ignores the product's Control Policy.

For products invoiced on Ordered Quantities, before any receipt:

`qty_received_at_date` = 0
`qty_invoiced_at_date` = 0

therefore:

`amount_to_invoice_at_date` = 0

The Accrued Expense wizard filters out lines whose
`amount_to_invoice_at_date` is zero:

https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/account/wizard/accrued_orders.py#L168-L178

As a result, the purchase order line is excluded entirely and the
wizard produces no accounting entries.

The same assumption is also used later in
`account.accrued.orders.wizard._compute_move_vals()` when computing
tax-included amounts, causing incorrect accrual values for
Ordered Quantities products whenever receipts and invoices differ.

Fix:
----
Introduce `_get_qty_to_invoice_at_date()`, mirroring the existing
purchase_method logic used by _compute_qty_invoiced().

The helper returns:

product_qty - qty_invoiced_at_date for Ordered Quantities
products;
`qty_received_at_date` - `qty_invoiced_at_date` for
Received Quantities products.

Now products invoiced on `Ordered Quantities` become
accruable as soon as the Purchase Order is confirmed;

---

opw-6290782

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284507
Forward-Port-Of: odoo/odoo#276435

Description of the issue/feature this PR addresses:

When `im_livechat` (or any page) boots the OWL web stack with no `[data-hotkey]` / `withOverlay` targets, pressing Alt still called `preventDefault()` in `hotkey_service`. That blocked browser shortcuts such as Alt+D (focus address bar) on websites that embed the livechat scripts.

See https://github.com/odoo/odoo/issues/267928

Current behavior before PR:

- Pressing the overlay modifier (Alt, or Ctrl on macOS mapped to `"alt"`) always set `overlaysVisible = true` and called `preventDefault()`, even when there were no hotkeys to overlay.
- A follow-up key (e.g. D while Alt is held) then also hit `preventDefault()` because overlays were considered visible.
- Loading `/im_livechat/loader/...` + `assets_embed.js` on an external site therefore broke browser Alt shortcuts.

Desired behavior after PR is merged:

- `addHotkeyOverlays` returns whether overlays were actually displayed.
- `preventDefault` on the overlay modifier runs only when there is at least one overlay target.
- Pages with no hotkeys (typical livechat embed) leave browser shortcuts alone.
- When hotkeys exist, Alt still shows overlays and cancels the default, same as before.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#284145

Step to reproduce
- install l10n_pe_edi_pos with demo and switch to PE company
- from settings> "Signature Provider" set it to SUNAT
- create a pos, enable "Basic Receipt" from settings
- open pos and fulfill a order
- from feedback screen, print > print basic recipt

Observation:
- `Amount In Word` is visible in basic receipt, we should not show such info in
basic receipt

Cause:
- commit [1] introduces the template `l10n_pe_edi_pos.pos_order_receipt`,
which adds the info block to the receipt using xpath
  `<xpath expr="//div[contains(@t-if, 'use_self_invoicing')]" position="before">`
- this inserts the block before the [target div](https://github.com/odoo/odoo/blob/1ace23afe8a937fc1dc53879f33ca591fd5d25b8/addons/point_of_sale/receipt/pos_order_receipt.xml#L70-L86), which is independent of
  the `basic_receipt` flag, causing the block to always be visible

[1] https://github.com/odoo/enterprise/commit/a0c4f841cde0fcfda0a0c57f865f0eff6b6d6afe

Fix:
- place the block so it is shown only when `basic_receipt` is false
- update the xpath expression to `prices` div ( here `basic_receipt` is false
  `//div[@name='prices']` with `position="inside"`
  
After fix (for full receipt)
<img width="257" height="349" alt="image" src="https://github.com/user-attachments/assets/3932cae1-3ceb-42ad-9ce4-16a9bd4fea7d" />



  opw-6383358

Forward-Port-Of: odoo/enterprise#125118

Description of the issue/feature this PR addresses:

The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db`
IndexedDB database, through a connection opened once, at module load, and cached for the
life of the page by the bundled idb-keyval (3.2.0), which cannot reopen it. When the
browser drops the origin's storage (eviction under disk pressure, site data cleared, a
privacy extension purging it), that connection is closed for good, and as
`updateAppBadge()` discards the promise returned by `idbKeyval.set()`, the rejection
reaches the user as a client error dialog.

Reported in production on a backend tab left open overnight (Firefox, 19.0):

```
UncaughtPromiseError > InvalidStateError
Uncaught Promise > IDBDatabase.transaction: Can't start a transaction on a closed database
```

Reproduced on a demo database below, with `?debug=assets` so that the stack points at the
source: lines 23 and 24 of the vendored idb-keyval are the `db.transaction()` call of
`_withIDBStore`, on the connection cached at module load.

<img width="1600" height="590" alt="error-dialog-debug" src="https://github.com/user-attachments/assets/e2b1aa46-501a-43d4-b4c0-20def1f529ef" />

Current behavior before PR:

1. log into the backend and leave the tab open
2. in the devtools, Application > Storage, tick *only* "IndexedDB" and click "Clear site
   data", as the browser itself does when it evicts the origin (the session cookie is left
   untouched, so the tab keeps working)
3. receive a message, or do anything else that changes the unread counter

The dialog opens, and opens again on every counter update for the whole life of the tab,
since the dead connection is never replaced; the counter is not saved any more either.

Two variants of the same code: the write also rejects, without anything being cleared,
when the origin runs out of storage quota (`QuotaExceededError`), and when the browser
forbids storage for the origin, `indexedDB.open()` throws during module evaluation, so
`store_service_patch.js` fails to load entirely.

Desired behavior after PR is merged:

The store is opened lazily, dropped whenever saving the counter fails, and the write is
retried once on a new connection: a single counter update after the connection was closed
saves it again. Opening the database is guarded too, for the synchronous throw. When the
retry fails as well the error is ignored, the app badge being cosmetic.

`mail/static/tests/web/app_badge.test.js` covers the retry, the recovery of a permanently
closed connection, and the database that cannot be opened at all. The three tests fail on
the current code with the uncaught `IDBDatabase.transaction` error.

Introduced in 19.0 by c04c4cb715902fe95618a15e18233cd001bdb304, and identical from
saas-19.1 to master, hence this PR against 19.0.

The corporate CLA for ERPVibe Limited is submitted in #283477.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#283480