Scalar conjunct in a ranged && statement gate is ignored

[thiremani]

Summary

A statement gate combining a scalar comparison with a ranged one via &&
ignores the scalar conjunct entirely: iterations are admitted as if only the
ranged part existed. Both operand orders reproduce, and both scalar and
collector destinations are affected.

Reproduce

x = -1
i = 0:3
c = [9]
c = x > 0 && i < 5 [i]
c

Expected [] (nothing admitted, since x > 0 is false; a ranged-gate
collector still commits — compare c = i < 0 [i], which correctly yields
[]). Actual:

[0 1 2]

Scalar destination, same gate:

x = -1
i = 0:3
s = 42
s = x > 0 && i < 5 i + 7
"-s"

Expected 42 (preserved). Actual 9 — every iteration was admitted and the
last one committed.

Reversing the operand order (i < 5 && x > 0) makes no difference.

Scope

Pre-existing: reproduces identically on 9fca83a, before the current branch.
Pure ranged gates (i < 0) and pure scalar gates (1 > 2) both behave
correctly; only the mixed && form drops its scalar side. Found while
verifying dead-store classification for gated collectors in PR #65 — the
write-commit behavior (which is all that classification needs) is unaffected,
but the committed content is wrong.

[thiremani]

Confirmed on master directly (origin/master = 9fca83a), scalar variant included:

x = -1
i = 0:3
s = 42
s = x > 0 && i < 5 i + 7   # s = 9 on master and on the PR #65 branch

Controls on the same master build isolate the defect to the mixed form: a
scalar-only gate (x > 0) preserves 42, and a pure ranged gate (i < 0)
preserves 42. Only scalar && ranged admits every iteration.

Likely origin is therefore the && statement-gate lowering (PR #61) or its
interaction with ranged gates (PR #59/#60), not anything on the PR #65 branch.