Two module manifests hold a `description` whose reStructuredText does not parse. Both are rendered by `ir.module.module._get_desc` (these modules have no `static/description/index.html`, so the RST path is the one used on the Apps page).

### `mail`

The line introducing the list of email-enabled documents is followed by a row of dashes. In reStructuredText an underline directly below a line of text makes it a section title, so docutils treats a 102-character sentence as a heading, then fails on the indented list that follows without a blank line:

```
<string>:38: (ERROR/3) Unexpected indentation.
<string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent.
```

These are logged every time the description is rendered, and the bullet list ends up rendered as a block quote instead of a list. The dashes are dropped, since the line is a regular sentence and not a section title, and the list is surrounded by blank lines.

### `l10n_tw_edi_ecpay`

The whole description is indented, which makes reStructuredText read it as a block quote. A section title is not allowed inside a block quote:

```
<string>:3: (SEVERE/4) Unexpected section title.
```

At SEVERE level this reaches the default `halt_level`, so rendering raises instead of returning a document and `_get_desc` falls back to showing the raw description in a `<pre>` block. The indentation is removed.

---

Checked by rendering the `description` of every manifest under `addons/` and `odoo/addons/` with the same docutils settings `_get_desc` uses: these were the only two that reported anything, and both are clean after the change.

Forward-Port-Of: odoo/odoo#284360

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

Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types.

This results in invoice reports showing the identification number next to an incorrect label.

This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in
their respective invoice template to match the selected identification type.

Steps to reproduce:
- Install a latam localisation (Uruguay or Guatemala)
- Change company to that country's Company
- Create a partner located in said country, ensure the identification number is set to something else than the default one
- Create an invoice for the partner, confirm it, and then Send it
- In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label

opw-6087359

related to: https://github.com/odoo/odoo/pull/260159

Forward-Port-Of: odoo/enterprise#122512