### Steps to reproduce:

**Issue 1:**
- Create a new link (e.g., type /link).
- The link editing popover appears.
- Click the Discard button.
- Link popover remains open at the bottom.

**Issue 2:**
- Insert an image (e.g., type /media)
- Convert image into link.
- URL input is not automatically focused when the image link popover opens.
- Popover remains open on Escape because it does not receive focus.

### Description of the issue/feature this PR addresses:

- Clicking `Discard` button kept the popover open. This happened because the original linkElement was disconnected and openLinkTools created a new empty anchor tag, causing a new popover to appear.
 - When converting an image into a link, the image link popover did not have a label input. As a result, the URL input did not receive focus by default.
- Pressing Escape key did not close the popover because it never gained focus.

### Desired behavior after PR is merged:

- If there is no valid link in selection, clicking `Discard` button closes the popover, and no new anchor tag is created.
- The URL input in the image link popover is now focused by default, and pressing the Escape key closes the popover.

task-4752206

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

Versions
--------
- 16.0+

Steps
-----
1. Enable abandoned cart reminder emails;
2. have an event with a limited number of seats;
3. open a cart for a ticket to the event;
4. abandon the cart;
5. have available seats fill up.

Issue
-----
You still get an email reminding you to buy the ticket, even though it's no longer available. As a consequence, you can still pay the sales order, but it won't get confirmed.

Cause
-----
There is no custom logic in place for `website_event_sale` to filter out abandoned carts with tickets that are no longer eligible.

Additionally, the `is_sold_out` field of tickets can be `False` while the event's `event_registrations_sold_out` field is `True`.

Solution
--------
- Add the event's `event_registrations_sold_out` field as a dependency to `event.event.ticket`'s `_comute_is_sold_out` method.
- Add an override for `_filter_can_send_abandoned_cart_mail` which filters out carts with tickets that are sold out, or events with no free places remaining.

opw-4453539

Forward-Port-Of: odoo/odoo#209928
Forward-Port-Of: odoo/odoo#199877

Before this commit, message actions are placed based on the type of message and its content:

- when message has bubble layout, they are placed next to the 1st line of bubble
- when message contains only attachments, they are placed next to the start of 1st attachment row
- otherwise, they are placed next to message header

The last case is a last resort which happens in non-discuss channels such as logged notes or tracking values and so on. All of them do not have "squashed" messages and the best natural placement is there in header. Message header is intended to be thin in content, so that it doesn't overpower with message content. However, message actions need to be big enough to be reached with a thumb. These considerations led to a compromise of thin header with message actions with negative margins.

This works well when message header is on a single line, but when it wraps to new line this doesn't look good because the negative margin puts it partially inside the header content.

This commit fixes the issue by changing the placement of message actions in mobile when displayed as a card, like on Inbox and History: the "..." is moved to the top-right corner of card.

This works because the card layout makes the top-right corner a natural position. This make it work like kanban views.

Note that this placement is best only in mobile: the card are short in width to make reaching message actions easy. In desktop, the message card can take almost the width of screen, so it makes it less practical than currently, close to message content.

Before
![Screenshot 2025-05-13 at 16 55 06](https://github.com/user-attachments/assets/7ce26c5d-f3a3-41fb-8a60-3736146eec7f)
After
![Screenshot 2025-05-13 at 16 54 27](https://github.com/user-attachments/assets/844e1d98-49a7-44b3-b8c9-68755385a863)

Forward-Port-Of: odoo/odoo#209689

The _compute_l10n_mx_edi_cfdi_cancel_id method is calling the following search

https://github.com/odoo/enterprise/blob/fd01cf3d57109424725727d7eb40afbe34ef67a9/l10n_mx_edi/models/account_move.py#L685-L691

```python
    move.l10n_mx_edi_cfdi_cancel_id = move.search([
        ('l10n_mx_edi_cfdi_origin', '=like', f'04|{move.l10n_mx_edi_cfdi_uuid}%'),
        ('company_id', '=', move.company_id.id)],
        limit=1,
    )
```

It is generating the following sql query

```sql
    SELECT id
    FROM account_move
    WHERE l10n_mx_edi_cfdi_origin :: text LIKE '04|55555-5555-5555-5555-555%'
        AND company_id = 1
    ORDER BY date DESC, 
        name DESC, 
        invoice_date DESC, 
        id DESC 
    LIMIT 1
```

Running a analyze for a database with ~7M of `account_move` records the result is

```txt
    Limit  (cost=73029.67..137055.68 rows=1 width=26) (actual time=1610.419..1637.035 rows=0 loops=1)
    ->  Incremental Sort  (cost=73029.67..649263.71 rows=9 width=26) (actual time=1600.475..1627.091 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Presorted Key: date
            Full-sort Groups: 1  Sort Method: quicksort  Average Memory: 25kB  Peak Memory: 25kB
            ->  Gather Merge  (cost=1000.46..649263.30 rows=9 width=26) (actual time=1600.466..1627.082 rows=0 loops=1)
                Workers Planned: 2
                Workers Launched: 2
                ->  Parallel Index Scan Backward using account_move__date_index on account_move  (cost=0.43..648262.24 rows=4 width=26) (actual time=1586.469..1586.469 rows=0 loops=3)
                        Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
                        Rows Removed by Filter: 2274213
    Planning Time: 0.197 ms
    JIT:
    Functions: 13
    Options: Inlining false, Optimization false, Expressions true, Deforming true
    Timing: Generation 3.044 ms, Inlining 0.000 ms, Optimization 2.327 ms, Emission 34.202 ms, Total 39.574 ms
    Execution Time: 1637.815 ms
```

PostgreSQL query stats from production returns the following top 1 slow query

```txt
Total Time  Average Time   Calls
4,981 min   1,351 ms       221,238
    SELECT "account_move"."id"
    FROM "account_move"
    WHERE (("account_move"."l10n_mx_edi_cfdi_origin"::text LIKE $1)
            AND ("account_move"."company_id" = $2))
            AND (("account_move"."company_id" IN ($3)) OR "account_move"."company_id" IS NULL)
    ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
    LIMIT $4
```

Creating the following index

```sql
    CREATE INDEX account_move_l10n_mx_edi_cfdi_origin_index
        ON account_move (l10n_mx_edi_cfdi_origin)
        WHERE l10n_mx_edi_cfdi_origin IS NOT NULL
```

Similar to define the field `account_move.l10n_mx_edi_cfdi_origin(index='btree_not_null')`

The same query analyze result is

```txt
    Limit  (cost=4.49..4.49 rows=1 width=26) (actual time=0.018..0.018 rows=0 loops=1)
    ->  Sort  (cost=4.49..4.51 rows=9 width=26) (actual time=0.017..0.017 rows=0 loops=1)
            Sort Key: date DESC, name DESC, invoice_date DESC, id DESC
            Sort Method: quicksort  Memory: 25kB
            ->  Index Scan using account_move_l10n_mx_edi_cfdi_origin_index on account_move  (cost=0.42..4.44 rows=9 width=26) (actual time=0.011..0.012 rows=0 loops=1)
                Index Cond: (((l10n_mx_edi_cfdi_origin)::text >= '04|55555-5555-5555-5555-555'::text) AND ((l10n_mx_edi_cfdi_origin)::text < '04|55555-5555-5555-5555-556'::text))
                Filter: (((l10n_mx_edi_cfdi_origin)::text ~~ '04|55555-5555-5555-5555-555%'::text) AND (company_id = 1))
    Planning Time: 0.147 ms
    Execution Time: 0.036 ms
```

It is ~9k times faster

Forward-Port-Of: odoo/enterprise#85427

This is a fix-of-fix.

#### Explanation of the first fix

Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used.

However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice.

To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice.

However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future).

#### The fix-of-fix (this PR)

To solve both those issues, here is what we do:
- now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change).
- if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too.

task-none

Forward-Port-Of: odoo/enterprise#85136

The aim of this commit is to:
    - avoid reporting negative amount in a 281.50 form which are rejected by the administration.
    - avoid reporting form with 0 value everywhere which are rejected by the administration.
    - avoid reporting a form with an amount < 250 EUR

Context:
The administration stated that we don't need to make any report that would be above 250 EUR.
(art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92)

https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802

Before this commit:
Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax.
Same for form with 0 everywhere.

Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported.

After this commit:
Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them.

task-id: None
This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL.

Forward-Port-Of: odoo/enterprise#85508