Here I would just accept any source IP, so that everything to your oculus rig gets into AC_VI initially, that way you can first test whether that helps at all before tightening the rules (especially since IPs of cloud devices often can change anytime).
Here I wonder about the value of doing that at the router? If the Oculus Quest is running on a specific internal PC maybe set the dscp in widows instead? See https://forum.openwrt.org/t/sqm-cake-and-being-a-twitch-streamer-upload-direction/62474/3?u=moeller0 for how that might work under windows 10.
Well, that is probably a consequence of ingress shaping being somewhat approximate, so unless you can establish a better traffic shaper at the ISP end of your access link (unlikely) your gaming stays sensitive to netflix starting (or any other similar traffic source starting).
That might be true, but then this is partly because that is what people where/are used to do from other QoS/AQM solutions. SQM's explicit goal is not being the one QoS/AQM solution that exposes all toggles and controls to power users, but rather doing the right thing for most users with the least requirements for twiddling and tweaking. But you can always fork the *.qos scripts and put in everything you like, so even for the tweakers SQM should at least offer a decent starting point and a reasonable framework to quickly test and change QoS configurations. That said, @ldir's great addition is someting I would like to pull into sqm scripts somehow, but I keep failing to free enough time to actually get this working and tested...
Well if you come up with a rue that allows you to unambiguously identify netflix traffic, you can always add an extra TBF instance to only throttle netflix (or try nft-qos/luci-app-nft-qos in addition to SQM)?