App Clip download stalls on IPv6 to Apple's edge, then App Clip Unavailable (FB25380604)

We run a live App Clip used by cafes in Saudi Arabia. Customers scan a QR code at the counter to follow their order. Some customers stay on the blurred loading screen for about a minute, then get App Clip Unavailable. One cafe reported more than five cases in its first days, and I watched another happen at a cafe today, on an iPhone showing 5G with Low Power Mode on. Try Again did nothing when we tested it, and a new scan opened the clip at once.

I reproduced it in 1 of 6 fresh downloads on an iPhone 17 Pro Max (build 23F84) on mobile data. The log shows:

1. appstored starts the download from iosapps.itunes.apple.com over HTTP/1.1 on IPv6, with timeouts(60.0, 604800.0).
2. TCP and TLS succeed and the request is sent.
3. 71 ms later a TCP RST arrives with a stale sequence number, and the stack drops it as out of window.
4. Retransmits go unanswered.
5. response_bytes=0, then NSURLErrorDomain -1001 after 60.4 s.
6. The install is cancelled, with no second attempt.

A parallel HTTP/3 request finished in 414 ms, so the network was up. The clip is about 0.7 MB, and both App Clip experiences are published.

Today I got the same stall without an iPhone. A Mac on an iPhone hotspot on STC mobile (AS39386) ran curl, opening a fresh HTTP/1.1 connection each time:

• iosapps.itunes.apple.com: IPv6 17 of 231 stalled, IPv4 0 of 89 stalled
• updates.cdn-apple.com: IPv6 5 of 60 stalled, IPv4 0 of 60 stalled
• www.apple.com, on a different CDN: IPv6 0 of 115 stalled, IPv4 0 of 85 stalled

Each stall looks the same: TCP and TLS finish, the request goes out, and no response byte comes back. The stalls hit many edge addresses. One edge, frmrs1-vip-bx-005, answers on both 2a01:b740:a11:f000::203 and 17.253.122.203, and it stalled on IPv6 only, so this looks like the IPv6 path rather than a bad node. This is one SIM over 17 minutes, and I haven't tested other carriers yet.

Repro from a Mac on an STC mobile hotspot:

for i in {1..60}; do curl -6 --http1.1 -s -o /dev/null -m 10 -I -w '%{http_code} %{time_starttransfer}\n' https://iosapps.itunes.apple.com/; sleep 4; done

My questions:

1. Is there anything a developer can do to avoid this or recover from it?
2. Is this a known issue with IPv6 to Apple's edge from Saudi mobile networks?
3. Could someone from the App Clips or edge network team look at FB25380604? It stops real customers at the counter, so it's urgent for us.