So I looked in to this further, and it did reproduce on an iPhone 4S, in Safari (despite the original report saying it did not happen there). So I can confirm it doesn't happen on an iPad Air 2, but does on an iPhone. That's not typical so is a bit of a surprise.
I am almost certain this is a bug in iOS itself, as I suspected. It appears it incorrectly restores the wrong sample rate on the second load. I wrote a report and filed it with Apple here: https://bugs.webkit.org/show_bug.cgi?id=154538
They typically are very slow to fix and ship bug fixes, it's taken about a year in the past. You can go ahead and tell everyone Construct 2 sucks or whatever, but it is Apple breaking your games, not us. The exact same code works in at least three other browser engines - Chrome, Firefox and Edge - so I am pretty sure there is nothing wrong with our code. So please direct your complaints to the WebKit bug report!
The good news is I found what looks like a workaround: we don't need to destroy and recreate the whole audio graph, it appears to fix it just by creating a fake audio context on startup, immediately closing it, then creating a second one and using that for the rest of the app. These kinds of workarounds can be fraught, it's really best that Apple fix it since I don't know how reliable this workaround is. But we'll ship it in the next beta release and see how that goes.