Yes, on using UltraEdit v25.20.0.88 and running this replace (or find) in single step mode, i.e. with first searching for next occurrence, viewing the found and selected text and then replace it, the displayed selection is wrong after the first two replaces. However, running from top of file Replace all results in correct behavior as far as I could see with inserting after this replace newline characters in input and output file to be able to compare the files and look on the nine differences caused by correct Replace all.

So UltraEdit has problems to display the file contents correct for the HTML file with more than 750 KB without any newline character which is extremely unusual. I have never seen such an HTML file in 20 years and in my opinion no browser should display such HTML files to force the file producer to format it useful.

The currently latest UltraEdit v27.00.0.24 shows the same behavior. Replace all works fine, but a step by step replace is working incorrect after second replace.

You can report this issue to  IDM support by email. But I suppose it will be rated as an issue with very low priority because of such a text file is really unusual and a nightmare for every text editor.

BTW: I recommend not using capturing/marking groups for parts of found string which are not back-referenced at all and avoid .*? on searching/replacing something in an HTML file as much as possible to avoid matching too much.

PS: I really hate webpages which embed binary data inside the HTML file which are usually stored in separate files like images and fonts referenced with a link. The reason is that I use an internet connection on which I have to pay for each MB. So I have disabled loading images and fonts in configuration of my browser for all websites except some specific websites configured manually different by me. But I have to pay for the download of binary data embedded in HTML file which are not displayed at all. The internet connection speed is also often very low (less than 20 KB/s) and so I have to wait a long time for getting displayed a page which shows just a few bytes of text, but contains several hundred KB of not used binary data because of embedding the data in HTML file instead of storing them in separate files linked from HTML file. I ban all websites which use such techniques to never load pages from them again.

I would have used in this case the search expression:

<video muted="1" preload="auto"[^>]+?src="([^\t\r\n."]+?)\.mp4"[^>]*?></video>

The matching replace string would be: <img src="\1.jpg">

[^>]+? ... searches non-greedy for any character including newline characters which can exist within a tag and being not a closing angle bracket or on finding the string src=". So after a positive match on <video muted="1" preload="auto" matching characters stop at the latest on > of the video tag. So if a video tag starts with <video muted="1" preload="auto", but does not contain src=", the search does not go beyond > of this video tag up to next src=" found anywhere in file.

[^\t\r\n."]+? ... this expression stops matching characters on either finding a dot - the dot of file extension .mp4 - or on finding a double quote, the double quote which marks end of value of tag src, or a horizontal tab, carriage return or line-feed which no file name can contain. So if the referenced video file does not have file extension .mp4, but for example .mpeg, this expression does not continue searching in file up to next occurrence of .mp4 on same line (in this special case nearly entire file) as .*? would do. So [^\t\r\n."]+? stops matching characters much earlier than .*? would do on video file not having file extension .mp4.

[^>]*? ... this non-greedy negative character set stops matching characters left to next closing angle bracket which is closing > of the <video tag.

This Perl regular expression replaces with Replace all also the nine video tags by image tags, but it is also of no help on step by step find and replace on the special HTML file.