> This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.

I think you're not familiar with web-related software.

> It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets.

This is exactly how the browser behaves, and why Javascript needs to be entirely async on the main thread.

For your application it should be very easy to spin up a render thread (pinned to a single core or whatever priority mechanisms you want to use) that loops, and use message passing to get the results from Tokio based futures.