I like this idea. It also reminds me of T188443: Wrap indicators in mw-parser-output class, which was fixed about a year ago.

I think we need to carefully decide which messages should get the wrapper. You wrote "edit notices", but it's an ambiguous term, people have used it to refer to either all of the edit intro messages shown above the edit form (including e.g. the message about editing while logged out), or just the "real" edit notices (those generated from MediaWiki:Editnotice-… messages).

I suggest adding it to the following to start with:

• The edit notices
• The "talkpagetext" message
• The "editintro" message (from &editintro= parameter)

I don't want to add it to all edit intro messages because of the potential for abuse from untrusted users. I don't think this would be a very severe problem, because no one reads these messages anyway, but still. One potential attack I can think of is using <templatestyles> in the page passed in the &editintro= parameter to hide the big red warning about the risks of user JS when editing Special:MyPage/common.js.

For reference, all possible edit intro messages can be found in this code: https://gerrit.wikimedia.org/g/mediawiki/core/+/1eb12c447019025b8cd7b6e1af06db256ec5cac8/includes/editpage/IntroMessageBuilder.php#140
and (mostly) all existing uses of <div class="mw-parser-output"> etc here: https://global-search.toolforge.org/?q=%5B%5E.%5Dmw-parser-output&regex=1&namespaces=8%2C10&title=%5B%5E.%5D%2B

In T337640#8887076, @matmarex wrote:

One potential attack I can think of is using <templatestyles> in the page passed in the &editintro= parameter to hide the big red warning about the risks of user JS when editing Special:MyPage/common.js.

Note that as long as the editintro is styleable, the attacker can just position it on top of the JS warning. On modern browsers this can be prevented with contain: paint (caniuse), not sure if that's considered good enough.

I think just adding it to edit notices without touching upon edit intros could be good enough. The only problem is that there might be an expectation for them to work the same in all cases, and that would obviously not be the case. TemplateStyles does have a mechanism of containing the styles using wrapper parameter (see docs), but it is probably impossible to require its use in certain cases like this.