I don’t see any other solution for this other than marking this bug as “false positive”.
Surprisingly it only marks this occurrence. Later in code we have similar “reuse” of variable with the difference that class arguments aren’t passed through dict unpacking. I’m not sure if that’s the cause.
The good news is that, while I managed to reproduce it on the current SonarQube LTS version (8.9.10), I could not reproduce it on the latest SonarQube version (9.7), so the false positive has already been fixed.
If you can live with flagging those issues as false positives until the release of the next LTS (which should happen early next year), then that may be the simplest course of action for you. Otherwise, you can also use the # NOSONAR comment on those patterns, or simply temporarily disable the rule.
Also, please note that this rule (like many others), is not designed to be run on test code. By specifying what your main code is and what your test code is (through the sonar.sources and sonar.tests properties - see here), you may get more precise analysis results.