fix(vm): combinations on lazy iterators skipped tail combinations 🔢 (#144)

## What

`CombinationsIter`'s pivot algorithm gave incorrect results for lazy
sources (any iterator that buffers on demand, e.g. the output of
`.enumerate()`, `.map()`, `.filter()`, etc.).

## Reproducer

```ndc
print([1, 2, 3, 4].combinations(2).list());
// [(1,2),(1,3),(1,4),(2,3),(2,4),(3,4)]    ← correct

print([1, 2, 3, 4].enumerate().combinations(2).list());
// [((0,1),(1,2)),((0,1),(2,3)),((1,2),(2,3)),((1,2),(3,4)),((2,3),(3,4))]
//                                ^ ((0,1),(3,4)) is missing and combinations are out of lex order
```

Eager sources (a list directly) were unaffected. Lazy sources missed
combinations whose rightmost index landed in the not-yet-pulled tail.

## Cause

`CombinationsIter` keeps a growing buffer of pulled elements and a list
of `indices` into that buffer. To produce the next combination it picks
the rightmost index that can still advance within the current buffer:

```rust
let pivot = match (0..k).rev().find(|&i| self.indices[i] < pool_len - k + i) { ... };
```

For an eager source, `pool_len` is the final size and the check is
correct. For a lazy source, `pool_len` is "what's been pulled so far".
When `indices[k-1]` reaches the end of the current buffer, the algorithm
decides "no room to advance the rightmost index" and falls back to
advancing an earlier index — even though one more pull would have
unlocked it.

The existing code did try to pull more, but only in the fallback `pivot
= None` branch, which only fires when *every* index is at its
current-pool maximum. In our trace above the algorithm picks pivot = 0
before reaching that fallback.

## Fix

Pull `indices[k - 1] + 1` worth of buffer *before* computing the pivot.
If the source still has elements, `pool_len` grows and the rightmost
index pivots as expected. If the source is exhausted the buffer stays
put and the existing pivot logic correctly falls back to an earlier
index.

## Tests

- New
`tests/functional/programs/900_bugs/bug0021_combinations_lazy_source.ndc`
covering the original 4-element case, the larger k = 3 case, and the
eager-source baseline.
- All 287 existing functional tests pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

Author: timfennis

ndc_vm/src/iterator.rs

@@ -462,34 +462,32 @@ impl VmIterator for CombinationsIter {
                 return None;
             }
         } else {
+            // For lazy sources: pull one more element before choosing the
+            // pivot. Without this, when `indices[k-1]` reaches the end of
+            // the current buffer the algorithm advances an earlier index
+            // (because `indices[k-1] < pool_len - 1` is false against the
+            // not-yet-extended pool), skipping combinations whose rightmost
+            // index lives in the unrealised tail. Pulling first makes the
+            // rightmost index pivot whenever the source still has elements,
+            // matching the eager-source lex order.
+            if self.source.is_some() {
+                let _ = self.ensure_index(self.indices[k - 1] + 1);
+            }
+
             let pool_len = self.buffer.len();
             if pool_len < k {
                 return None;
             }
 
             let pivot = match (0..k).rev().find(|&i| self.indices[i] < pool_len - k + i) {
                 Some(p) => p,
-                None if self.source.is_none() => return None,
-                // For lazy sources: pulling one more element always unlocks index k-1.
-                // When pivot = None, indices[j] = pool_len - k + j for all j, so
-                // indices[k-1] = pool_len - 1. After one pull, pool_len grows by 1 and
-                // indices[k-1] < new_pool_len - k + (k-1) holds.
-                None => {
-                    if !self.ensure_index(self.buffer.len()) {
-                        return None;
-                    }
-                    k - 1
-                }
+                None => return None,
             };
 
             self.indices[pivot] += 1;
             for j in (pivot + 1)..k {
                 self.indices[j] = self.indices[j - 1] + 1;
             }
-            // For lazy sources, buffer up to the new last index.
-            if !self.ensure_index(self.indices[k - 1]) {
-                return None;
-            }
         }
 
         // All indices are in-bounds: direct indexing is safe.

tests/functional/programs/900_bugs/bug0021_combinations_lazy_source.ndc

@@ -0,0 +1,28 @@
+// CombinationsIter over a lazy source (e.g. `.enumerate()`) used to skip
+// combinations whose rightmost index lay in the not-yet-pulled tail.
+// `indices[k-1]` would hit the buffer end before the source was drained,
+// and the pivot algorithm would advance an earlier index instead of
+// pulling one more — yielding combinations out of lex order and missing
+// some entirely. Fix: pull `indices[k-1] + 1` before computing pivot.
+
+// Eager (list) reference — correct for both pre- and post-fix.
+assert_eq([1, 2, 3, 4].combinations(2).list(), [(1, 2), (1, 3), (1, 4), (2, 3), (2, 4), (3, 4)]);
+
+// Lazy (iterator) source — this is the path the bug lived in.
+assert_eq(
+    [1, 2, 3, 4].enumerate().combinations(2).list(),
+    [
+        ((0, 1), (1, 2)),
+        ((0, 1), (2, 3)),
+        ((0, 1), (3, 4)),
+        ((1, 2), (2, 3)),
+        ((1, 2), (3, 4)),
+        ((2, 3), (3, 4))
+    ]
+);
+
+// Larger k — exercise the multi-pull-per-pivot path.
+let triples = [10, 20, 30, 40, 50].enumerate().combinations(3).list();
+assert_eq(triples.len, 10);
+assert_eq(triples[0], ((0, 10), (1, 20), (2, 30)));
+assert_eq(triples[-1], ((2, 30), (3, 40), (4, 50)));