Fused-while micro-optimisations: nested-while rescan and redundant final eval

[ausimian]

Surfaced by the CM14 fused-while review (follow-up to #163). Two small, low-priority inefficiencies in the fused-while path (c_src/program.cpp). Neither affects correctness or the generation hot path.

1. Nested while rescans the inner body each outer iteration

When native_compiled fuses a loop whose body itself contains a while, the outer body takes the non-fused replay_program branch and re-enters replay_program every outer step. Each re-entry recomputes fuse_body for the inner loop:

// c_src/program.cpp:215
const bool fuse_body = ctx.fuse_loops && !contains_top_level_while(body_p);

so contains_top_level_while(inner_body) (an O(instrs) scan) runs once per outer iteration. Only nested loops are affected — generation is a single flat loop — but a precomputed has_while flag on Program would remove the scan entirely.

2. Redundant final eval on the compiled while path

After the loop, the while arm has already realised the loop-carried state with mx::eval(state) on the last iteration (c_src/program.cpp:236). The eval_mode == 3 handler then calls mx::eval(roots) again (c_src/program.cpp:435) over those same arrays. mx::eval on already-realised arrays is a no-op, so this is harmless — a tidiness nit only.

Severity: low (perf/cleanup).