DowkerCofaceSimplexStream

The dual-side Dowker complex (geometry.dual), same threshold and keep-criterion -- see the class doc's "duality is the point" paragraph. Not memoized: cheap to construct (just wraps geometry.dual, itself memoized on DowkerGeometry), and a caller driving both sides concurrently would otherwise share mutable coface-generation state (currentDimensionCache et al.) it should not share.

Contract .iterator below relies on: the domain must be contiguous starting at 0 -- defined for 0, 1, ..., k for some k (or empty, or all of the non-negative integers), never with a gap. .iterator stops at the first dimension this is undefined for, so a non-contiguous domain (defined at d but not at d - 1) would silently truncate iteration instead of skipping the gap. Every implementation in this codebase already satisfies this (a simplicial complex can't have a d-simplex without its (d-1)-dimensional faces, so "no cells at d" implies "no cells at any dimension beyond d" too); a new implementation must preserve it.

Dimension-major: all of dimension d before any of dimension d + 1.

MUST NOT be implemented as Iterator.from(0).filter(iterateDimension.isDefinedAt)....fold(...) (a real, confirmed bug this replaced -- see .claude/WORKLOG-cohomology.md): Iterator.filter on an infinite source can never prove "no more matches ahead", so once past the last dimension iterateDimension is defined for, it spins forever searching for a d that will never come -- and Int silently wrapping from Int.MaxValue to Int.MinValue after ~2^31 iterations can eventually feed a huge negative d straight to iterateDimension instead, surfacing as a BinomialCoefficient range exception rather than a hang. .takeWhile instead stops at the first d this is undefined for and never asks about any d beyond it, relying on exactly the contiguous-domain contract documented on iterateDimension above.

The number of elements in this collection, if it can be cheaply computed, -1 otherwise. Cheaply usually means: Not requiring a collection traversal.

Returns a scala.collection.Stepper for the elements of this collection.

The Stepper enables creating a Java stream to operate on the collection, see scala.jdk.StreamConverters. For collections holding primitive values, the Stepper can be used as an iterator which doesn't box the elements.

The implicit scala.collection.StepperShape parameter defines the resulting Stepper type according to the element type of this collection.

• For collections of Int, Short, Byte or Char, an scala.collection.IntStepper is returned
• For collections of Double or Float, a scala.collection.DoubleStepper is returned
• For collections of Long a scala.collection.LongStepper is returned
• For any other element type, an scala.collection.AnyStepper is returned

Note that this method is overridden in subclasses and the return type is refined to S with EfficientSplit, for example scala.collection.IndexedSeqOps.stepper. For Steppers marked with scala.collection.Stepper.EfficientSplit, the converters in scala.jdk.StreamConverters allow creating parallel streams, whereas bare Steppers can be converted only to sequential streams.

Filtration value, reversed (so smaller-under-this-ordering means YOUNGER, matching SimplexStream's own established convention), then dimension, then COLEXICOGRAPHIC order on the vertex set (via simplexIndexing's own combinatorial-number-system index) -- the "lexicographically refined" tie-break Ripser's own apparent-pairs machinery (Definition 3.2/Proposition 3.9, see RipserCohomologyContext) is defined in terms of, so using it here keeps this stream's ordering consistent with every other Ripser-flavored piece of this codebase, not just internally self-consistent -- deliberately not the plain lexicographic tie-break FilteredSimplexOrdering uses.

Fixes a real, previously-confirmed bug (.claude/WORKLOG-cohomology.md): a bare Ordering.by(filtrationValue) has no tie-break at all, so two DIFFERENT simplices tied at the same filtration value compare as equal -- not a total order. This happens by construction on any Vietoris-Rips complex with a triangle, since a triangle's filtration value always equals that of its own longest edge; CellularHomologyContext bakes a stream's filtrationOrdering into Chain.reduceBy's SortedMap, so two cells that compare equal collide as a single map key and the reduction silently garbles pairings for that complex.

iterateDimension sorts each dimension's bucket by filtrationOrdering.reverse -- deliberately .reverse on this SAME Ordering object, not an independently-built "oldest first" comparator: two individually-valid orderings that disagree on tie-break direction let a coface sort before its own tied facet, corrupting Chain.reduceBy's pivot table the same way the no-tie-break bug did. A stream's iteration order and its filtrationOrdering (pivot order) must be THE SAME total order, one the consistent reverse of the other.