Steps to reproduce:
- Set a company's tax rounding method to round_globally (the be_comp default, required by Belgian law).
- Import a multi-line UBL invoice where more than one line's amount doesn't divide evenly under the invoice's tax.
- Open the invoice: some lines' displayed Subtotal doesn't match what's actually posted on the line's balance, and the invoice's Untaxed Amount doesn't equal the sum of the displayed line subtotals.

Cause of the issue:
account.move.line._compute_totals() rounds price_subtotal/price_total one line at a time. Under round_globally, the balance actually posted on a line is decided by _sync_tax_lines()/_get_rounded_base_and_tax_lines(), which round the whole move together and redistribute a few cents of delta across its lines. Since _compute_totals() never grouped lines together and never added that redistributed delta back into price_subtotal, the two values could permanently disagree as soon as a move had more than one line.

Solution:
Round a move's relevant lines together in _compute_totals(), the same way _get_rounded_base_and_tax_lines() does for balance, and fold the redistributed delta into price_subtotal/price_total. The full set of a move's lines is re-fetched from move_id.line_ids on every call (not just the lines in self), because _sync_tax_lines() itself writes the final amount_currency back onto each line one at a time - and amount_currency is one of this compute's own dependencies, so that write would otherwise re-trigger it in isolation and undo the grouped result.

opw-6431707