perf: chunk the lazy seq producers

A lazy seq cost a cons cell, a memoizing thunk and a closure per element, which
put `(count (range 1000000))` at 299 ms where the eager version had been 23 ms.
Chunking amortizes that over a batch: range, map, filter/remove and take now
realize up to 32 elements per step and hand back one kChunk instead of 32
cons cells.

A new kChunk value kind holds the realized run, an offset into it, and the rest
of the seq. Cursor indexes a chunk where it lies rather than copying its
elements out, and still follows cons/lazy links one at a time, so chunked and
unchunked seqs compose freely -- `(concat [1 2] (range))`, `(cons 0 (range 10))`
and `(map f (range) (cycle [10 20]))` all work unchanged.

The visible consequence is that demand rounds up to a batch: taking 3 elements
of a mapped seq runs the fn 32 times. That is what Clojure does, and every case
in examples/chunking.clj was checked against a real Clojure run -- the 32/64
call counts, the interop cases and the infinite-source cases all agree. It does
mean map's fn must not be relied on for per-element side effects; doseq is the
tool for that. examples/lazy.clj says so where it counts calls.

filter draws up to 32 source elements per step and emits whichever pass, rather
than pulling until 32 have passed, so a rare match in a long or infinite source
still costs a bounded amount per step: `(first (filter #(= % 5000) (range)))`
does not realize 32 matches.

reduce also stops materializing its source through toSeq and streams it
instead, which is what lets a fold over a lazy seq hold a chunk at a time.

Compute excluding startup, best-of-N round-robin:

                     before   after
  seqs                853 ms  342 ms
  lazy-bench            0 ms    0 ms   (early exit unaffected)
  persistent-bench    120 ms  120 ms

Two things measured and rejected rather than kept: copying a chunk's elements
into the cursor was worth ~30 ms of the total, and skipping the destructor's
drain worklist for kinds that never queue anything was worth nothing at all --
not enough to justify touching the mechanism that keeps a long chain from
overflowing the stack at teardown.

What remains between this and the eager numbers is the boxed Value: every
mkInt still allocates, which a separate measurement puts at 16 ms per million.
Folding a long seq also still retains its head through the argument that holds
it, so `(reduce + (map inc (filter even? (range 5000000))))` peaks at 713 MB.
Both are their own piece of work.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>