Steps to reproduce:
- Create a 21% sale tax, included in price, and set it on a product with a price of 2.95 (tax included).
- Create a 0% tax, included in price, replacing the 21% tax through a fiscal position (e.g. an intra-community one).
- In the PoS, add the product to an order, then set a customer using that fiscal position.

Current behavior:
The 0% tax is applied but the total stays 2.95: the 21% tax included in the price is never stripped. The invoice and the session closing entry are computed the same way, so the customer is overcharged by the amount of the included tax. The same flow is correct in Sales, where `_reset_price_unit` adapts the price unit through `_adapt_price_unit_to_another_taxes`.

Expected behavior:
The total drops to 2.44 (2.95 / 1.21), like in Sales.

This commit adapts the price unit wherever the fiscal position maps the taxes, on both sides:
- in the frontend base line preparation (order lines and the product flows receiving a fiscal position), using the existing `adapt_price_unit_to_another_taxes` helper,
- in `_prepare_base_line_for_taxes_computation` and `_compute_amount_line_all` on `pos.order.line`, so invoices, session closing entries and backend refunds stay consistent with the amounts paid in the PoS.

Only lines with `price_type == 'original'` are adapted: a price manually set by the cashier, discount and tip lines are kept as is, like in Sales.

`create_ui_order_data` is also updated to mock the real frontend: it used to send the mapped taxes as the line `tax_ids` (the frontend sends the product taxes and maps them at computation time), which made the backend path untestable.

opw-6275952

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