After a few more rounds on Try, I have a partial diagnosis:
The test performs three touch drags. The first two are intended to bring an iframe into view, and the third one is intended to drag content inside the iframe. The iframe is not initially layerized, so the third touch-drag needs to go through the dispatch-to-content / SetTargetAPZC codepath.
On the failing test runs, for some reason (I don't understand why yet) the second touch drag targets the iframe rather than the root content document. As a result, the second touch drag takes the dispatch-to-content codepath.
When the touch-start event for the second drag arrives at content, content determines the target and checks if it's layerized. Since it's not, it sets a displayport, and takes the "layers-dependent" SetTargetAPZC codepath, where it registers a post-refresh observer and sends the SetTargetAPZC notification when the observer fires. This ensures that the SetTargetAPZC notification arrives at APZ after the layer transaction which tells APZ about the scroll id of the newly layerized iframe.
Now here's the key part: the main thread is busy (or the emulator is slow etc.), and takes a while to get around to doing a paint with the new displayport and fire the observer. As a result, the third touch-drag, which also targets the iframe, not only arrives at APZ before the SetTargetAPZC message arrives (and therefore also takes the DTC codepath -- which, in and of itself, is fine), but also arrives at content before the refresh observer from the second drag fires.
At this point, the check that the iframe is layerized passes (because it's checking for the displayport property, which has by now been set), so content figures it's fine to send the SetTargetAPZC notification for the third touch-drag right away, rather than taking the layers-dependent codepath. However, the layer transaction containing the iframe's scroll id hasn't been sent yet, and therefore the SetTargetAPZC notification, mentioning the iframe's scroll id, arrives at APZ before the layer transaction that establishes that scroll id. As a result, the APZC lookup results in a null APZC, we set that as the target, and end up dropping the touch events of the third drag.
Now, this mode of failure wouldn't happen in this test if the second touch drag were targeted correctly. However, the fact that the SetTargetAPZC notification can race the layer transaction in this way in the case where two subsequent input blocks target an element that isn't initially layerized, is a latent bug that should be fixed either way.