Here's the series of events going on there:

• The page is saved containing the bad link.
  • The Parser's output includes the bad link in the ParserOutput metadata.
  • The job for inserting the externallinks table rows for the page runs. For our bad link it gets 0 indexes from LinkFilter::makeIndexes(), so makes no insertion for this bad link.
    • The 0 index entries comes because wfParseUrl() returns false, which in turn is because PHP's built-in parse_url() returns false, which seems to be because it tries to interpret the ":0000" at the end as a port number and finds that invalid.
• The subsequent edit is made, not modifying the bad link.
  • Again, the Parser's output includes the bad link in the ParserOutput metadata.
  • ConfirmEdit checks the externallinks table to find the existing links in the page. to detect whether any new links have been added in the edit being made. Since there's no externallinks entry for this bad link, it thinks it's new and so triggers a captcha.

I also get a captcha request if the string tel:// is already on the page. See https://en.wikipedia.org/w/index.php?title=User:Suffusion_of_Yellow/CaptchaBug&diff=968045535&oldid=968045267.

And another one: http://Draft:Getscreen.me. I got a CAPTCHA (from a non-AC account) even for a null edit on Wikipedia:Teahouse until I made this change.