When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#118759

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

Ticket [link](https://www.odoo.com/odoo/project.task/5117571)
opw-5117571

Starting version 2.1.4 of markupsafe, they decided to adapt the striptags function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used striptags with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster.

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better.

The benchmark cases are in the form `<case_description>_<number_of_tags>`. We can see that the only cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                               | Regex µs | Current µs   | Speedup  |
|----------------------------------------|----------|--------------|----------|
| plaintext_no_tags_50k_words            | 2937.05  | 2795.78      | 0.95x ← current_implementation |
| html_entities_only_no_tags_5k               | 4843.88  | 4818.92      | 0.99x ← current_implementation |
| comments_only_1k                       | 382.75   | 1985.56      | 5.19x ← regex_old_implementation |
| comments_containing_tags_1k            | 234.88   | 1243.65      | 5.29x ← regex_old_implementation |
| comments_only_50k                      | 21047.84 | 21081024.01  | 1001.58x ← regex_old_implementation |
| comments_containing_tags_50k           | 13948.90 | 11301014.95  | 810.17x ← regex_old_implementation |
| short_tags_5k                          | 915.32   | 28235.99     | 30.85x ← regex_old_implementation |
| short_tags_20k                         | 3603.37  | 876001.98    | 243.11x ← regex_old_implementation |
| short_tags_50k                         | 10648.04 | 9064394.50   | 851.27x ← regex_old_implementation |
| nested_divs_1k_deep                    | 148.99   | 880.14       | 5.91x ← regex_old_implementation |
| nested_divs_10k_deep                   | 1730.14  | 54162.25     | 31.31x ← regex_old_implementation |
| tags_with_many_attrs_2k                | 1165.15  | 16554.24     | 14.21x ← regex_old_implementation |
| tags_with_many_attrs_20k               | 12659.77 | 7297957.10   | 576.47x ← regex_old_implementation |
| multiline_tags_20k                     | 10227.63 | 5476065.12   | 535.42x ← regex_old_implementation |
| mixed_comments_with_tags_text_2k            | 309.79   | 3034.69      | 9.80x ← regex_old_implementation |
| mixed_comments_with_tags_text_10k           | 1593.39  | 79993.58     | 50.20x ← regex_old_implementation |

This PR is needed because requirements.txt in Odoo specifies the following dependency:
MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688


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

### What & why

`odoo db load` always calls `restore_db(..., copy=True)`, which forces the
generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is
the right default when *duplicating* a database, but it breaks the intended
behaviour when *moving* a database between servers: Enterprise subscription codes
are registered against the database UUID, so regenerating it deregisters the
moved database.

The web database manager already lets the user choose between copying and moving
(the `copy` flag of the `/web/database/restore` route), but the CLI exposed no
equivalent and forced a copy unconditionally. The CLI is the better tool for
server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits
and can run unattended or interactively.

### Steps to reproduce the current limitation

1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID)
2. On server B: `odoo db load mydb mydb.zip`
3. `database.uuid` has changed → the subscription is deregistered

### Fix

Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`,
keeping the original UUID. The default remains `copy=True`, so existing behaviour
is unchanged.

```sh
odoo db load mydb mydb.zip          # unchanged: restore as a copy (new UUID)
odoo db load --move mydb mydb.zip   # new: restore as a move (keep the UUID)
```

### Backport request

This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well.
Those are precisely the versions that ship the `odoo db` CLI subcommand, so the
fix is applicable to all of them — which is why the backport range is 16.0 → 19.0
and stops at 16.0.