Okay this one has a ~600ms spike in the initial idle period. At that point sqm/cake have not really engaged at all... this also fits with cake's own pk_delay and av_delay from your first post, no sign of ~600ms delays here.
This is promising, could please you get a free registration and redo the test with a longer duration according to the recommendations in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803. I want to see whether "local" test stay spike free for longer times, so maybe you could increase the test duration (to the maximum allowed) and run, say 10 tests in a row and paste the results here?
This looks okay, but I fear that this test is not reporting the veridical worst-case RTTs, but rather some robust estimate that ignores outliers...
You had mtr running during the test? Anyway the worst RTT pattern strongly indicates something intermittent, this is not a typical overload pattern.
Please repeat your measurements with the high-res bufferbloat configuration option and longer run-times...
Is that precisely every two seconds?
BTW, that address range indicates carrier grade NAT (see https://tools.ietf.org/html/rfc6598), so one issue might be your ISPs CG-NAT AFTR's being overloaded. Do you also have IPv6 available and could switch?
These spikes will be visible in the detailed results, so no need to record animated gifs/videos (then again these are nice to look at, so thanks).
When you test wired, please completely disable the wifi radios in your router, otherwise other RF signals might interfere with your router.
Can you access the error counters in your DSL modem? Maybe the the modem sees cyclic RF ingress?