101 wip for as template effect

// `for` as a void effect pump: `! each` fires per iteration, NO terminal branch
// (no `| done`, no count — that would be pay-for-nothing on every loop). The
// iterable is template-substituted into the Zig `for`; the body calls the
// `! each` handler symbol. This is the real shape of the `for` we're building —
// 400_071 (effect_branch_multifire_void) proves the void-pump shape works; the
// only delta here is the templated iterable.
~import std/io

~pub tor loop { r: i32 }
! each usize

~[template]proc loop|zig {
    for ({{ r }}) |item| {
        each(item);
    }
}

// JS sibling. Same pin — a templated iterable driving a void effect pump — with
// each half spelled in the mechanism its target implements.
//
// The iterable: `0..3` is captured as Expression TEXT, and a Zig range is not a
// JS iterable, so the `parse_range` filter classifies it and the range case
// lowers to a counting loop (the performance-correct form, not Array.from).
// Identical treatment to koru_std's own `for|template|js`.
//
// The effect call: `{{ h.inlined_link[scope] }}` mints the
// `__koru_inline_scoped_N` marker js_emitter resolves in
// emitInlineBodyResolvingContinuations. The Zig half's bare `each(item)` relies
// on the in-scope Handlers alias the Zig emitter emits at a splice site; the JS
// emitter emits no such alias, so the marker IS the JS spelling of "call the
// handler here" — again what `for|template|js` uses. What is pinned is the
// templated iterable either way; the handler call is the machinery around it.
~[template]proc loop|js {
    {% const __r = parse_range(r) %}{% if __r.is_range %}for (let item = {{ __r.lo }}; item < {{ __r.hi }}; item++) {% else %}for (const item of {{ r }}) {% endif %}{
        {% for h in effects["each"] %}{{ h.inlined_link[scope] }}(item);
        {% endfor %}
    }
}

~loop(r: 0..3)
! each v |> std/io:print.blk {
    v {{ v:d }}
}