* feat(wasm): wire wasm-bindgen-test into CI and expand binding coverage
The WASM binding already had 8 wasm_bindgen_test cases checked in but
they ran only when someone manually invoked `wasm-pack test` locally —
CI never executed them, so a breakage between the Rust core API and the
JS surface would only surface in user reports.
Two changes:
1. **New CI job `wasm-test`** in `.github/workflows/ci.yml` runs
`wasm-pack test --node bindings/wasm` on every push and pull-request.
Uses Node-runtime mode (no headless browser needed), pins
`taiki-e/install-action` for `wasm-pack`, installs the
`wasm32-unknown-unknown` target.
2. **10 new `#[wasm_bindgen_test]` cases** in `bindings/wasm/src/lib.rs`
covering families that the existing 8 tests did not touch:
- Family 4 — Macd multi-output batch shape (3-component packing)
- Family 5 — Bollinger {upper, middle, lower} ordering invariant
- Family 10 — FisherTransform streaming roundtrip (recursive DSP)
- Family 16 — SharpeRatio reset semantics, MaxDrawdown monotone-
uptrend invariant, ValueAtRisk constructor validation
- Cross-family — reset returns indicator to warmup (3 shapes),
warmup_period parity with wickra-core, NaN input rejection
does not advance warmup counter
No production code changed; additive tests only. Total wasm test count
goes from 8 to 18.
* fix(wasm-tests): WasmAtr's hand-coded wrapper has no is_ready accessor
The new `reset_returns_indicator_to_warmup` test in this branch called
`atr.is_ready()` but `WasmAtr` is hand-coded (not generated by the
`wasm_scalar_indicator!` macro) and does not expose `is_ready` on the
JS surface — that pattern is reserved for macro-generated scalar
wrappers.
Replace the second leg of the test with `WasmEma` so the test exercises
two macro-generated scalars whose `is_ready`/`reset` semantics are
guaranteed by the same code path. The candle-input lifecycle is
already covered by `candle_input_streaming_matches_batch_and_lifecycle`.
Workspace clippy locally green:
- cargo clippy -p wickra-wasm --all-targets -- -D warnings
- cargo check -p wickra-wasm --target wasm32-unknown-unknown --tests
* fix(wasm-tests): Bollinger batch layout is 4 floats per bar, not 3
The new `bollinger_batch_orders_upper_mid_lower` test indexed the batch
output as `[u0, m0, l0, u1, m1, l1, ...]` (3 floats per bar) but the
actual WasmBb::batch layout is `[u0, m0, l0, sd0, u1, m1, l1, sd1, ...]`
— four floats per bar including stddev. The assertion read an upper
band against a middle from the previous bar, which can violate the
expected upper >= middle ordering and made the test fail intermittently.
Switch the stride from `* 3` to `* 4` so we read upper / middle / lower
from the same bar. Also add an `is_finite()` precondition so the test
fails with a clear "warmup positions unexpectedly NaN" message rather
than a confusing NaN-comparison if the dataset ever shrinks.
* fix(wasm-tests): drop redundant wasm-test job; existing WASM build covers it
The CI workflow already had a `WASM build` job that runs
`wasm-pack test --node bindings/wasm` after building. The
`wasm-test` job I added in cc961b3 duplicated that step and was
the only one whose `taiki-e/install-action` SHA was wrong, so it
also kept failing on a non-resolvable action reference.
Removing the duplicate keeps the test coverage (it lives in the
existing WASM build job) and gets rid of the unresolvable SHA.
kingchenc
6c2ddf319f