@Krinkle Above work (moving the processing to post-processing, behind ParserCache) has been merged & deployed yesterday evening.
I don't think there's anything left to do at this moment, so please let us know if you should sport more issues, or comment/close if you feel this has sufficiently been resolved.
FYI we plan to move forward with the experiment next week - let us know if you have concerns.

1-2 days should suffice to have your A-B test take effect everywhere at once

I was expecting significantly longer caches - that's great news!
I just moved everything into Parsoid post-processing: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/1346698 - another quick look would be much appreciated, @Krinkle :)

Does this feature really require sitting in a layer above and separate from the rest of MediaWiki?

Post-processing could definitely work here, if not for the caveat that it's an experiment for now - not a full rollout.

Dropping priority to low because these are edge cases.

@Etonkovidova both of these are parser egde cases.

I think we've taken this about as far as we can for now. Calls to external services are gone; the remaining more intensive processing is avoided as much as possible, and cached where not.

Turns out this is no longer an issue in recent iOS builds, but I did manage to replicate in older versions.

Pending confirmation from @JScherer-WMF

The 2 backported patches should get rid of these crossed-out sections; about 2/3 of the overall cost in this hook (and external calls)

Random unsolicited subjective comment: I 'm not sure I find this to really be an improvement.
While there was sometimes some duplication (which IMO wasn't too bad, given that there's usually some lead text pushing the infobox further down) of images also visible in the infobox, I find that omitting those images leaves me slightly more confused WRT what those images in the carousel are: they're often more specific and require more context to grasp immediately how exactly (or even that) they're related to the article. The infobox images are more generic and obvious.
Also: if we do want to tackle the duplication, we might want to omit *all* lead section images rather than only those in the infobox - these are often enough both even more visible/higher up, and larger, making them a bigger problem than the infobox images. E.g. https://en.wikipedia.org/wiki/History_of_New_York_City_(1898%E2%80%931945)

Works for me, but I was never able to replicate the weird smaller-image thing that Justin had seen, so would be nice if @JScherer-WMF could take another look at this one to confirm!

Oops. While I'm sure it's ok to be resolved, I just meant to move forward

Above patches should fix things, I believe. I've slapped them together hastily, so please review thoroughly!

In production and this example seems fixed!

In production and works as it's supposed to!

This is now on beta (https://en.wikipedia.beta.wmcloud.org/wiki/Special:SemanticSearch), but the semantic portion just shows the same lexical results.
That is expected, given that en/beta is not a wiki where semantic search is supported, so the additional param (requesting semantic results rather than the usual ones) does nothing.

My bad! When I added more details to this ticket, I was thinking about making sure that obviously-not-semantic queries are still being routed through lexical search (on the results page), but this ticket was created to avoid displaying the CTA in the first place!