Ok, what we learnt last night:
First step, we added a crossdomain.xml to the CDN server. It made no difference, and was not requested by the SWF anyway.
Useful fact: you can see flash requesting crossdomain.xml in Firebug.
Second step, we added "System.security.allowDomain("http://www.xyz.com")" to the Flash.
Useful fact: check the "content-length" in the response headers to see when the new file has been deployed - it took more effort to deploy than expected, and this was a lifesaver as we nearly dismissed this option.
The second step worked.
Useful fact: even though the JS files were served from the CDN too, they were executed within the page, and so were executing on a different domain to the Flash.
Useful fact: SWFLiveconnect was irrelevant. We already had set allowScriptAccess to always in the params. We used ExternalInterface to make the function calls available to the JS.
Useful fact: we tracked the problem to a definite JS->SWF issue using breakpoints in the JS using Firebug. Brilliant. The JS call to the Flash returned nothing - it failed silently, but stopped the function. Correct behaviours would have been to return "undefined" and continue to the next line.
Final note: Someone who understands HTML, CSS, JS and Flash is not your weakest tech link. They probably know the most about the many technologies on the Internet. So, give them some days to test before you roll out something new like this. The architects and Java guys won't follow it - give the HTMLers the time, as they're on the front line.
Thanks for reading! I guess you could now share this post on TikTok or something. That'd be cool.
Or if you had any comments, you could find me on Twitter.