dasLLAMA: deltanet chunked-vs-recurrent multi-chunk prefill diverges on M1 (test_deltanet red)

[borisbat]

tests/dasLLAMA/test_deltanet.das — the "deltanet chunked prefill == recurrent (Qwen3.5-0.8B, multi-chunk)" probe fails on M1 Max: the post-prefill argmax differs between the two modes (first assert: expected 1, got 220; the 8-token greedy continuation then diverges at several steps, e.g. expected 198, got 348). The 20-token single-partial-chunk parity fixture in the same file passes.

Repro (M1 Max, Qwen3.5-0.8B-Q8_0.gguf in the models dir):

bin/daslang -jit dastest/dastest.das -- --test tests/dasLLAMA/test_deltanet.das

Facts established while bisecting (it surfaced during an unrelated dasMetal Phase-7 session):

• Pre-existing, not from the working tree: reproduces identically with modules/dasLLAMA + tests/dasLLAMA checked out from origin/master (d54ce30b6), with a stashed working tree, a wiped .jitted_scripts cache, and a freshly rebuilt binary.
• Deterministic after a JIT-cache wipe: consecutive runs fail with the same token ids (1→220, 198→348). Values shifted once across a cache wipe, so the divergence magnitude is sensitive to codegen, but each build diverges stably — this looks like a real math/state bug in the chunked path (or its interaction with this box's thread count) rather than a flaky race.
• The 150-token case = two full 64-token chunks + a partial tail, i.e. the chunk-boundary / batched-conv-history handoff territory the probe was written to cover.
• CI likely never runs this: the test gates on the 0.8B model being present, so lanes without the model skip it silently.

Not investigated further (out of scope for the dasMetal arc that tripped over it); flagging for the qwen35/deltanet owner-arc.