I did not mean to come across as insulting by including the build/Quilt "basics". I was hoping that might help others who might want to try the patch.
But back to your questions/points, you are correct in that it doesn't seem to add up regarding the location of the patch and the resulting build. Let me try to move the patch to package/kernel/ath10k-ct/patches and check the result.
Obviously, I will update my original post accordingly if needed.
EDIT
So I recreated the patch in package/kernel/ath10k-ct/patches and recompiled. It did build and I flashed the image to my R7800. However, I am now seeing this kernel warning repeated constantly in the logs:
ath10k_pci 0001:01:00.0: failed to increase tx pending count: -16, dropping
Clients are unable to connect, so I had to revert back to my previous image. At this point I am not sure what to make of this whole thing. Based on my testing, it is apparent something changed right at the time I originally tested the dql patch. But based on your experience, which I'm sure is far beyond mine, the dql patch would not have been in play.
Again, not sure what to make of it all at the moment. The data points to a change, but apparently it was not dql--and no idea what else at this point.
EDIT 2
I removed the dql patch again and checked out htt_tx.c here /openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/ath10k-ct-smallbuffers/ath10k-ct-2020-04-29-3637be6f/ath10k-5.4. I do see this:
void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
{
lockdep_assert_held(&htt->tx_lock);
htt->num_pending_tx--;
if ((htt->num_pending_tx <= (htt->max_num_pending_tx / 4)) && htt->needs_unlock) {
htt->needs_unlock = false;
ath10k_mac_tx_unlock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
}
}
That is the change Ben introduced here: https://marc.info/?l=linux-wireless&m=158808593808807&w=2
I'm thinking now the results I shared from testing were instead due to Ben's change for the "Restart xmit queues below low-water mark." It fits with the timing. If that is the answer, I certainly apologize for attributing the data to the wrong change. Certainly unintentional on my part. 
