There is no unique index on the externallinks table, so the duplicates are okay, but the delta logic of the LinksUpdate should avoid duplicates. I would not expect many pages with duplicates, but there are some:

MariaDB [dewiki_p]> select count(*) from ( select 1 from externallinks group by el_from, el_to_domain_index, el_to_path having count(*) > 1 ) as t;
+----------+
| count(*) |
+----------+
|    37302 |
+----------+
1 row in set (5 min 10.756 sec)
MariaDB [dewiki_p]> select count(*) from externallinks;
+----------+
| count(*) |
+----------+
| 33489989 |
+----------+
1 row in set (7.205 sec)

The domain index https://.com.qha. gets reversed, but https://.qha.com would be invalid and is internally build as https://qha.com, so the code is comparing wrong values and cannot remove this invalid one.
The only way to handle also invalid values from the database seems to change the way the ExternalLinksTable class is handling the delta, it should not modify the existing values before comparing, so it needs a 2d-array and calling LinkFilter::makeIndexes earlier.

The patch set fixed mediawiki that it deletes the invalid rows on the next edit, on null edit, edit on transcluded template or on forced linkpurge via api's action=purge.

It does not handle duplicate rows and removes the duplicates. When an invalid row exists with duplicates (as in the task description) all of them gets deleted.
Hopefully no new duplicates should be created, but that was not tested or explicit enforced.
Closing as the duplicates are not the main reason for the task, some of them should be invalid rows and are gone after the fix.

See the roadmap for the next deployment (should be 1.42.0-wmf.7) - https://www.mediawiki.org/wiki/MediaWiki_1.42/Roadmap and verify with https://versions.toolforge.org/