Migrate Iter.filter_star to the Rust iterator backend

[Copilot]

Iter.filter_star was still using the Python fallback while adjacent iterator adapters had already moved to the Rust-backed _tools module. This change migrates filter_star to the same backend without changing its external behavior, including support for unpacking non-tuple iterable elements.

• Rust iterator adapter

  • Adds _tools.FilterStar in rust/src/tools.rs
  • Unpacks each yielded element into positional arguments, evaluates the predicate, and yields the original item when it passes
  • Preserves the existing runtime contract for any iterable element, not just tuple

• Python API wiring

  • Switches Iter.filter_star() to delegate to tls.FilterStar(...)
  • Removes filter_star from the remaining Python-side Rust migration TODO list

• Typing surface

  • Adds the internal _tools.pyi stub for FilterStar
  • Extends Iter.filter_star overloads with a generic iterable fallback so strict typing matches the runtime behavior

• Regression coverage

  • Adds focused coverage for filter_star with non-tuple iterable elements to guard the preserved unpacking semantics

from pyochain import Iter

data = ([0, "a"], [1, "b"], [2, "c"])

result = Iter(data).filter_star(lambda index, _item: index % 2 == 0).collect()
# Seq([0, "a"], [2, "c"])

[OutSquareCapital]

Why is this needed?

[OutSquareCapital]

Does this work with the overloads at the call site?

[OutSquareCapital]

trivial tests like this should be documented in the docstring.

[OutSquareCapital]

So at each iteration we copy each element in a Vec to unbind it?? this must be slow as fuck, as this been measured?

I didn't see any benchmark result by the way.

I'm not sure we want to support non-tuples.

We already don't for the for_each_* methods anyway.