False Negative: ContinueInFalseLoop.ql misses `do ... while(false)` loops once `false` is stored in a local.

# False Negative: ContinueInFalseLoop.ql misses `do ... while(false)` loops once `false` is stored in a local.

Version
codeql 2.24.3

## Checker
- Checker id: `Likely Bugs/Statements/ContinueInFalseLoop.ql`
- Checker description: This checker detects a 'continue' statement inside a 'do' loop whose condition is always false, meaning the continue will never actually re-run the loop body.

## Description of the false negative
Both samples are still `do` loops whose condition is false and therefore cannot loop back after `continue`. The only difference is that the literal `false` is first assigned to a local variable.

That should still be a direct hit for `Likely Bugs/Statements/ContinueInFalseLoop.ql`.

## Affected test cases
### `PosCase1_Var1.java`
`never` is a constant false value, so the `continue` still cannot re-enter the loop body.

```java
// A do loop with a literal false condition contains a continue statement targeting that same loop should be flagged as a positive case.
package scensct.var.pos;

public class PosCase1_Var1 {
public static void main(String[] args) {
final boolean never = false;
do {
// continue inside do with false condition
continue;
} while (never);
}
}
```

### `PosCase1_Var5.java`
`flag` is initialized from `Boolean.FALSE` and never changed. This is still the same impossible loop-back case.

```java
// A do loop with a literal false condition contains a continue statement targeting that same loop should be flagged as a positive case.
package scensct.var.pos;

public class PosCase1_Var5 {
public static void main(String[] args) {
boolean flag = Boolean.FALSE;
do {
// continue inside do with false condition
continue;
} while (flag);
}
}
```

## Cause analysis
The miss is surprisingly basic. The query appears to require a literal `false` at the loop condition and loses the result as soon as that same value is stored in a local.

For developers, these are the same bug. Whether the condition is written as `while (false)` or `while (never)` should not matter.

## References
None known.

Start with Likely Bugs/Statements/ContinueInFalseLoop.ql and inspect how it evaluates do-loop conditions when false is stored in a local. Review the affected PosCase1_Var1.java and PosCase1_Var5.java cases, then run the checker tests to confirm both cases are flagged while the existing literal-false behavior remains covered.

Written by the indexing model from the issue text.