I’m tempted to say you should know if you understand ADR by now. So maybe the best suggestion is: make sure to follow the links above and ensure you understand how it’s supposed to work.
What gateway are you using? Is that confirmed downlink that is shown in the screenshot received by the device?
And which LMIC are you using? You’ll want one that is actively maintained, such as GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment (and not GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives., which was mostly tested for EU868, I think).
If you’re already using MCCI, then I’m afraid you’ll need to capture a lot of full LoRaWAN packets from the gateway’s traffic, and decode those to see if after 64 packets without receiving a downlink they indeed have their ADRAckReq bit set until TTN responds with a LinkADRReq MAC command in FOpts. I don’t think that the online decoder shows FCtrl.ADRACKReq, but maybe it does when it’s set. If not: it’s the 6th bit in FCtrl:
To force a downlink for debugging (not as a final solution, even if it works) you could indeed set the ACK bit for a few uplinks (but certainly not for all) when TTN should have enough details to piggyback a LinkADRReq on the confirmation downlink.
But to force a downlink for debugging it may be easier to just schedule one in the device’s Overview page in TTN Console (just a random value) when you think that it’s time TTN could be waiting for an opportunity to send the LinkADRReq. (So, you can already do that long before the device should set its ADRACKReq bit after 64 uplinks without a downlink.) Even more: your screenshot shows you’re already sending some downlinks, so it seems there’s no need for neither a confirmed uplink nor some dummy downlink.
Next, you can decode the full LoRaWAN packets of the downlinks too, to see if FOpts contains some MAC command. (See an example for AU915.) Maybe TTN simply has determined that SF10 is the best you can do…
Just in case the state that TTN knows is very much out of sync with the ABP device’s state, you may want to delete the device and register it again. Or better yet: if the downlinks are working for you, just switch to OTAA first, before trying to fix ADR. And remember, no matter what: use MCCI LMIC.