Of course you cannot control incoming traffic’s bandwidth directly. The maximum you can do is to slow down the delivery of the incoming traffic from the ISP to the local destination, and if the transport or application protocol of a given session supports some kind of feedback to the sender, this will make the sender reduce the bandwidth towards your end device, but this doesn’t work for all protocols.
Also, you seem to have misunderstood the role of connection marking. Many tutorials say “assign a connection-mark first, and later translate it to packet-mark” but they don’t explain why. The idea is that if the classification conditions are complex, it saves CPU to evaluate them just once, when handling the initial packet of each given connection, and save the result in the form of a connection-mark to the context of the connection as maintained by the connection tracking module of the firewall, so every subsequent packet of that same connection doesn’t need to be re-checked for all the classification conditions because the connection tracking module assigns it that connection-mark as a metafield, which the subsequent stages of the firewall can work with just like with the actual fields of the packet headers. This is also the reason why the connection-state=new is part of the conditions of the action=mark-connection rule - to avoid re-classification of every packet by the potentially complex match conditions.
Each connection can have at most one connection-mark; if any packet belonging to an already marked connection matches an action=mark-connection rule, the connection-mark of the connection gets rewritten by the new new-connection-mark value.
In your rules below, each connection gets connection-marked with either Upload-Client1 (if initiated by one of the clients) or Download-Client1 (if initiated from outside towards one of the clients acting as server in that particular connection), thanks to the connection-state=new match condition which only matches on the initial packet of each connection.
To place the download and upload packets to different queues, you have to let the action=mark-packet rule match on more than just the connection-mark (which must be common for both directions, otherwise it loses its purpose), e.g. the in-interface(-list). So what comes in via WAN is download, hence it will get a packet-mark Download-Client1; what does not come in via WAN is upload, hence it will get a packet-mark Upload-Client1.