Short answer: you have to update SonarLint. The issue you report has been fixed long time ago:
Long answer: maintaining such matrix would be very difficult. When we release a version of SonarLint, we know at the moment what is the compatibility with existing SonarQube versions. But to keep the matrix accurate on the long run, we would have to re-validate older versions continuously.
Our strategy is to follow SonarQube LTS lifecycle. New SonarLint releases always support SonarQube LTS and later. In practice, to give more time for companies to move from one LTS to another, we are even supporting the former LTS as long as possible (currently still supporting 6.7).
On the other side, SonarQube web API maintain backward compatibility on a best effort approach, so older versions of SonarLint should work with newer SonarQube versions, but with no strong commitment. We usually try to anticipate cases where compatibility will be broken, to give enough time for people to update.
As a general rule, we consider that people will update SonarLint regularly. I know some companies are “locking” developer environments for years, but then we assume a consistent ecosystem (if you use an old SonarLint, you should use a contemporary SonarQube).
Regarding Eclipse compatibility, you can have a look at the marketplace (but again, this is only for the latest version of SonarLint):
2020-06 (4.16), 2020-03 (4.15), 2019-12 (4.14), 2019-09 (4.13), 2019-06 (4.12), 2019-03 (4.11), 2018-12 (4.10), 2018-09 (4.9), Photon (4.8), Oxygen (4.7), Neon (4.6), Mars (4.5), Luna (4.4), 2020-09 (4.17)