Description of the issue/feature this PR addresses:

Fixes #279931.

`initElementForEdition()` ([`html_editor/static/src/utils/sanitize.js`](https://github.com/odoo/odoo/blob/18.0/addons/html_editor/static/src/utils/sanitize.js#L20-L31)) removes the `width`/`height` attributes of every `<img>` in the editable and replaces them with an inline pixel style. Its comment says *"The attributes will be re-applied on save"*, and for the pipeline it was written for that is true: `convert_inline` re-adds `width` from `style.width` when it inlines a body for email.

But `initElementForEdition()` is called unconditionally from [`editor.js`](https://github.com/odoo/odoo/blob/18.0/addons/html_editor/static/src/editor.js#L109), on every editor start, for every editable — website pages, blog posts, any `html` field on `html_editor`. Outside the mail path nothing re-applies the attributes.

This was added by #213786 (`opw-4863515`, forward-ported as #216958 / #216986 / #217002 / #217017 / #217023) to fix a real problem in the *email template* editor, where `convert_inline` had added `width`/`height` for email-client compatibility and those attributes then prevented resizing an image back to its default. That fix is right for that path. This PR only narrows where it applies.

Current behavior before PR:

Open any editable containing an image with intrinsic dimensions, type one character, save. The stored markup is permanently rewritten:

```
before  <img src="…" alt="x" width="960" height="540" loading="lazy">
after   <img src="…" alt="x" loading="lazy" style="width: 960px; height: 540px;">
```

There is no way back — on the next edit `img[width]` no longer matches, so the inline style stays.

It is not cosmetic. Intrinsic `width`/`height` is how a browser reserves the box before an image loads, and an inline `width` beats the stylesheet rule that keeps the image responsive. Measured at a 375px viewport with a 960×540 image in a 319px column, after one keystroke and a save:

* the image renders 960×540 — **641px of overflow**, and the document's `scrollWidth` goes from 375 to 1153, so the page scrolls sideways;
* the derived `aspect-ratio` becomes `auto`, so a `loading="lazy"` image below the fold lays out at **zero height** until it decodes — the CLS the attributes exist to prevent;
* where a stylesheet sets an explicit `aspect-ratio`, an explicit `width` **and** `height` together decide the used size, so the declared ratio goes inert and the crop is lost.

Desired behavior after PR is merged:

The rewrite becomes opt-in through a `removeForcedImageDimensions` config flag — following the existing `allowInlineAtRoot` precedent, which is threaded the same way — and is set in `HtmlMailField.getConfig()`, the field whose `getEditorContent()` runs `toInline()`. That is the one path that puts the attributes back, and `HtmlComposerMessageField` inherits it. Every other editable keeps the author's markup.

Behaviour in the email-template editor, which `opw-4863515` was about, is unchanged.

Adds `html_editor/static/tests/utils/sanitize.test.js` covering both directions: with the flag the attributes still move into an inline style; without it they are left alone; an image with no dimensions is untouched either way.

Targeting **18.0** as the oldest affected branch — #213786 targeted 18.0 and the block is byte-identical on `18.0`, `saas-18.4`, `19.0`, `saas-19.1` and `master`.

---

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