test(codegen): the sweep sees an inline product as a divisor (#395)

[kevinlincg]

Closes the sweep half of #395. It does not move CCI, CORREL or WILLR.

Correcting the stated cause first

#395 says the sweep misses these because scan_expr's if let Expr::Var(v) = &**den
never matches an inline expression. There is no such line — the sweep iterates
names(den), every variable the denominator mentions, so it does look inside
0.015*tempReal2.

The actual defect is one step further in: it treats "a variable inside the divisor is
guarded" as "the divisor is guarded". Both functions read as guarded and neither is.
That matters because it changes the fix — matching Expr::Var on the denominator would
not have helped.

The third arm

A divisor that is an inline product or quotient (seen through sqrt/fabs, which carry
their argument's zeroness), with no guard naming the expression itself, but with some
guard attempting a bound on an operand.

Operand detection here is looser than the other arms use, on purpose. CORREL's guard is
ssX > 1e-14*sumX2 — a relative band, not a literal floor — and the strict
tests_var_against_zero rejects it. That strictness is right where soundness is the
question and wrong here, where the question is only whether someone tried to bound the
operand. The strict test stays exactly where the_sweep_detects_a_reintroduced_er_defect
pins it.

Pinned in the direction that matters, as with the other two arms:
the_inline_arm_clears_when_the_guard_names_the_divisor rewrites CCI's guard onto
0.015*tempReal2 and requires the finding to disappear, so an arm that flagged every
inline product unconditionally would fail it.

WILLR is not covered, and should not be

#395 groups it with the other two; it is a different defect. Its divisor is
Var("diff"), not an inline expression, and it guards diff itself — the right target.
Its problem is that an exact != 0.0 is too weak for sub-epsilon residue, which is the
#107 band-strength question. Stretching this arm to reach it would mean flagging guards
that name their divisor correctly, which is the one thing the arm exists to distinguish.

Seven more with the same shape, reachability unproven

Beyond CCI and CORREL, the arm flags the Hilbert family — HT_DCPERIOD, HT_DCPHASE,
HT_PHASOR, HT_SINE, HT_TRENDLINE, HT_TRENDMODE and MAMA. All guard
Im != 0.0 && Re != 0.0 and then divide by atan(Im/Re)*rad2Deg
(ht_dcperiod.c:318-319 and its twins). Both operands being non-zero does not make the
quotient representable: a small enough Im/Re underflows to 0.0, and atan(0.0) is
exactly 0.0.

That is a structural argument, not a measurement. I did not construct an input that
reaches it, and #395 does not mention these functions, so the rows say "shape matches"
and nothing stronger. If you would rather they were not recorded until someone
reproduces one, say so and I will drop them.

All nine annotated OPEN, none patched

Moving these guards changes output on the affected windows — a decision about shipped
functions, the same line drawn for KAMA in #383/#385 and STOCH in #392. #395 also
notes CCI and WILLR are pre-cutover, so --codegen compares them against the frozen
oracle and LEGACY_TOL may need re-measuring; that is part of the fix, not of the sweep.

no_annotation_is_stale covers the follow-through: when a guard does move, its row stops
being flagged and the suite says so.

Verification

cargo clippy --all-targets clean, 938 generator tests green, ta_regtest green. One
file changed; no generated source touched.