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

Currently, the Luxembourg Balance Sheet incorrectly maps accounts
`502000` and `503000` under the `III. Investments` section.

**Steps to reproduce:**
- Install the `l10n_lu_reports` module and switch to the `LU Company`.
- Navigate to Accounting > Accounting > Journal Entries and create and
  post two journal entries:
  - One with account `502000 Own shares or own corporate units`.
  - Another with account `503000 Shares in undertakings with which...`.
- Navigate to Reporting > Balance Sheet and check the `III. Investments` section.

**Observation:**
- `502000 (Own shares...)` is wrongly added under `3. Other investments`.
- `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`.

In the generated XML report:
- `502000 (Own shares...)` balance is added inside `<NumericField id="195">`.
- `503000 (Shares in undertakings...)` balance is added inside 
   `<NumericField id="209">`.

**Expected behavior:**
According to the Luxembourg documentation mapping tables [1],
- Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`.
- Account `503000 (Shares in undertakings...)` should be mapped 
  to `<NumericField id="195">`.

**Root Cause:**
At [2], the `account_codes_formula` values are incorrectly assigned:
account code `503` is mapped under `2. Own shares`, while account code
`502` is mapped under `3. Other investments`. This reverses the expected
mapping of the two accounts in the Balance Sheet report.

[1]:
https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables

[2]:
https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348

opw-6275340

Forward-Port-Of: odoo/enterprise#128386

Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
  emojis)
- search a term and select emojis without closing the picker (shift+click on
  desktop, plain click on mobile)
- clear the search with backspace

=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().

This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.

This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.

partial backported PR: https://github.com/odoo/odoo/pull/281104

Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)



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

Forward-Port-Of: odoo/odoo#286551
Forward-Port-Of: odoo/odoo#284372