Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.

Steps to reproduce
1. Create a product at $30 with a 15% tax-excluded tax (total = $34.50)
2. Sell and pay the order
3. Edit the tax and toggle price_include = True
4. Open POS, go to Orders > Paid — the order total shows $30 instead of $34.50
5. Click Refund — the refund total also shows $30 instead of $34.50

Issue
https://github.com/odoo/odoo/blob/130c5266e0fc37f64f58f67b44c84130643bec20/addons/point_of_sale/static/src/app/store/models.js#L1067-L1090 get_all_prices() recomputes prices from price_unit using current tax objects, ignoring price_subtotal/price_subtotal_incl already serialised in the order JSON. When price_include changes on a tax after an order is paid, the historical total is lost.

https://github.com/odoo/odoo/blob/130c5266e0fc37f64f58f67b44c84130643bec20/addons/point_of_sale/static/src/app/store/models.js#L1580-L1608 this.locked was assigned after the orderlines loop, so Orderline.init_from_JSON could not use it to distinguish paid from draft orders.

https://github.com/odoo/odoo/blob/130c5266e0fc37f64f58f67b44c84130643bec20/addons/point_of_sale/static/src/app/screens/ticket_screen/ticket_screen.js#L653-L668 _prepareRefundOrderlineOptions passed price_type: "automatic" which triggered a fresh get_all_prices() with current taxes, producing the same wrong total on refunds.

Solution
Move this.locked assignment before the orderlines loop. When locked, pin price_subtotal/price_subtotal_incl from JSON in Orderline.init_from_JSON and return them early in get_all_prices(), scaling by qty/lineQty so per-unit display calls (get_all_prices(1)) remain correct.

Read amount_total/amount_tax from JSON and return them directly in get_total_with_tax()/get_total_tax() for locked orders.

Carry price_subtotal/price_subtotal_incl in the refund detail snapshot and inject them (scaled by partial-refund ratio) as extras on the refund orderline.

opw-6097256