Interpreter: Pine v6 na propagation + na comparison semantics

[FellowTraveler]

Summary

This is the na-semantics slice of #49, split out (as offered there) so each piece can be reviewed on its own. The code is unchanged from #49 — the commits are cherry-picked as-is. The three split PRs are independent: each compiles and passes the full workspace suite standalone (cargo test, just fmt-check, just clippy all clean on this branch), and any merge order is conflict-free.

Both changes were found while running real Pine strategies through pinecone bar-by-bar and diffing against TradingView's strategy tester.

1. feat(interpreter): Pine v6 na propagation

Operators previously raised Expected number type errors when an operand was na, and NaN was truthy (n != 0.0 is true for NaN in IEEE 754). TV's semantics (na in the reference):

• arithmetic and ordering comparisons with na yield na;
• and/or use three-valued logic — false and na is false, true or na is true, otherwise na;
• an na condition in if/while/ternary takes the false/else branch;
• na doubles as a function: na(x) tests whether x is na.

Internally, new to_number()/to_bool() return Option (None = na) so na can propagate; the existing as_number()/as_bool() keep their signatures for builtins (na → NaN / false), so builtin implementations are unaffected.

Test: new integration script testdata/basics/na_propagation.pine pins all of the above.

2. fix(interpreter): ==/!= with an na operand yield na

==/!= were missed by the na-propagation commit because they route through values_equal (structural equality) rather than to_number(), so 1 != na returned true — e.g. dayofweek != dayofweek[1] fired on the first bar of a series. values_equal itself is unchanged (switch keeps structural matching).

Tests: crates/pine-interpreter/tests/na_comparison.rs (4 tests).

Note: the two commits are ordered — one of the na_comparison.rs tests exercises an na != result used as an if condition, which requires the na-falsy-in-if behavior from the first commit — so they travel together in this PR.

Validation

Beyond the tests in this PR, the combined change set (this PR plus its two siblings from #49) was validated externally: we run full Pine strategies through pinecone one bar at a time and diff the emitted entries/exits against TradingView's own strategy-tester CSV export for the same symbol/timeframe. With all of them in place, two real strategies match TV 100% — 56/56 signals on a 4H strategy and 21/21 on a daily strategy, including exit-reason order comments — over their full comparison windows.

[FellowTraveler]

Pushed a follow-up commit (835ecd4) that extends the na-operand handling to the Value::Number(NaN) case — the companion to the earlier Value::Na-operand fix. In Pine na is float NaN, and NaN can reach ==/!= wrapped as a plain Number rather than the Na value (e.g. ta.* functions folding an all-NaN window return NaN as a number). The prior guard only short-circuited on the Na value, so NaN != NaN still evaluated true via structural comparison instead of yielding na. The commit adds an is_na_operand helper (matches Na or a NaN-valued Number) guarding both the Eq and NotEq arms; values_equal and the relational operators are unchanged. New tests cover the direct comparison results and the ternary-else behavior.

Note: not (x == y) where the comparison yields na now differs from a strict two-valued reading — na propagates through not (na stays falsy in conditions), matching TradingView.

[FellowTraveler]

Pushed two more follow-up commits:

9a1ddf5 — relational operators treat NaN-valued Number operands as na. This completes the comparison class started in 835ecd4: to_number() maps Value::Na to None (which the relational match arms already turn into Value::Na), but a Value::Number(NaN) operand — a computed NaN such as math.sqrt(-1.0), or a ta.* all-NaN window — passed through as Some(NaN) and the raw float comparison yielded Bool(false), which e.g. not then flips truthy where TradingView produces na (falsy). The four relational arms now get the same is_na_operand guard Eq/NotEq use; the to_number match remains as the fallback for Series-wrapped na. All six comparison operators now handle both na forms uniformly.

d100a99 — division and modulo by zero yield na. In Pine, x / 0 and x % 0 evaluate to na — a plain value, not a runtime error; the script continues. The Div/Mod arms instead returned Err(RuntimeError::DivisionByZero), aborting the whole script. The errors-corpus fixture testdata/errors/division_by_zero.pine pinned that must-error behavior, which doesn't conform to TradingView, so it's reclassified to testdata/basics/division_by_zero.pine asserting the na results (same pattern as basics/na_propagation.pine). One honest caveat: the integer-literal case (1 / 0 → na) is asserted from Pine's general na-on-zero-divisor semantics — Pine defines no int-specific division error — rather than from an int-specific documented rule. The RuntimeError::DivisionByZero variant is retained since removing public API feels like your call; it just has no construction sites now.

New tests: relational × na, relational × Number(NaN) (failed pre-fix), no-na boolean sanity; div_by_zero.rs pins 1/0, 0/0, -3%0, na/0 → na plus non-zero sanity. Full workspace suite, fmt, and clippy clean at each commit.

[ferranbt]

Please write this as interpreter testdata cases.

[ferranbt]

Why was this test removed?