Steps to reproduce:
- Add a product to a draft order, do not pay
- Open the same PoS in a second tab of the same browser (the first tab
  is sent to the backend), or reload while a draft is being removed
- Pay the restored draft, then make and pay a new order

Issue:
Both orders carry the same pos_reference (e.g. 264-3-000701). The number
is printed on both receipts and sent to fiscal integrations that use it
as the unique invoice number.

Cause:
The receipt number is issued client side by DeviceIdentifierSequence,
a per-device counter kept in localStorage that all tabs of a browser
share. When a draft is removed, its number is pushed on
`unsynced_number_stack` to be reused by the next order.

`removeOrder` pushes the number synchronously, then deletes the order
from IndexedDB without waiting for the transaction. If the page unloads
before it commits (the tab is closed by another tab opening the same
PoS, a redirect to the backend, a reload), the next load restores the
draft from IndexedDB with its number while the stack hands that same
number to the next new order. Both are then created on the server with
different uuids and the same pos_reference: the server only
deduplicates by uuid.

Fix:
Before a new order takes a number, drop from the reuse stack the numbers
still used by the unsynced orders this device holds: a draft restored
from IndexedDB, or one whose copy another tab removed, still owns its
number. The push stays synchronous, so a cancelled order is still
replaced by one reusing its number.

opw-6558992

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

Forward-Port-Of: odoo/odoo#287667