Well, that is why in sqm-scripts (and qos-scripts, and qosify, and ...) we create an artificial bottleneck for ingress traffic on the OpenWrt router, under many conditions (with responsive traffic) that allows us to meaningfully control the ingress traffic as well, good enough so that QoS hierarchies can be built on top if one desires.
I would recommend to start out with sqm-scripts/luci-app-sqm configured for per-IP-fairness with cake/piece_of_cake.qos as a stop-gap measure while you research how to built your preferred elaborate QoS hierarchy.
Per-IP-fairness will equitably divide your capacity between active machines/IP addresses, and within each IP-address equitably between flows. This is NOT the end state you want to reach from your description, but it should be a better place to "wait in" while building your desired QoS tree.
For a number of users 9but by no means all) per-IP-fairness is already good-enough and they stopped right there... (sqm-scripts also offers different priority modes for the cake qdisc, like diffserv3/diffserv4/diffserv8 that might allow you to add a sprinkle of classic priority QoS on top of per-IP-fairness).
That is a bit tricky, as you need to perform this sorting before HTB gets hold of these packets... that means e.g. raw tc filter commands or qosify's eBPF approach, or moving the ingress shaper onto an interface inside the NAT domain so iptables/nftables can be used...
This really depends on what you want to achieve.
Technically correct, but it turns out traffic shaping on the ingress side, while not as strict as on the egress side works pretty well, and it is doing so since more than a decade... Sure it will not stop a DOS attack and have problems with unresponsive traffic, but for most "normal" traffic mixes it works surprisingly well.
For typical TCP Reno, the reverse ACK traffic will be around 1/40 the volume of the forward data traffic, so if you want to "choke" the ingress data traffic you would need to shape the egress traffic down to < 1/40 of the data rate, technically doable, but not a great idea...
Start with sqm-scripts instantiated on your WAN interface, as a stop-gap measure until you have figured out what you want to do with HTB. You can also have a look at sqm-scripts' simple.qos script for a simple 3 tier HTB set-up with some mild filterings.