I've seen strategies of redirecting requests to the read-only region
in case of repeated operation failures against the primary, but can't
find anything on how to handle direct read access redirection.
From the Geo-Failover Process, you do not need to change your application’s URIs – all existing URIs will work the same before and after a geo-failover as the storage account account.<service>.core.windows.net
DNS entry would be updated to point from the primary location to the secondary location.
I expect there to be some insulation due to the CDN nodes caching the
files, but is there any way to redirect to the secondary read-only
region in case of sustained outage?
However, for an RA-GRS, since there is a delay in the geo-replication, in the event of a regional disaster it is possible that the data that has not yet been replicated to the secondary region will be lost after the failover. Due to the Microsoft-managed failover, we could not control it more even you have a CDN, you do not enable automatic fallback to the secondary endpoint, see this feedback.
Is it possible/advisable to set up traffic manager nodes between the
CDN and the storage?
Currently, it does not support blob storage under traffic manager but it might be possible for the external endpoint. Read the feedback.
In this case, you can use set up failover across multiple Azure CDN endpoints with Azure Traffic Manager. If so, you will have two CDN profiles and have full of control of it. In a typical failover scenario, all client requests are first directed to the primary CDN profile; if the profile is not available, requests are then passed to the secondary CDN profile until your primary CDN profile is back online. Using Azure Traffic Manager in this way ensures your storage account is always available.
Additionally, you could have a knowledge of storage account failover (preview) in Azure Storage. Customer-managed account failover (preview) enables you to fail your entire storage account over to the secondary region if the primary becomes unavailable for any reason.